S 城的疫情来得猝不及防，老板虽然很不情愿，但还是要放大家回去居家办公。然而这波居家办公刚好赶上公司人事变动大的时候，两个烫手山芋一起扔到了 HR 怀里，例会之后又转手把山芋扔给了我们部门的CTO，要求建立公司内部的人力资源 SaaS 系统。 CTO 告知我们要做这个系统之后，看到我们一边抢菜一边从云端投来的怨念的眼神，于是进行了一波调研，最终找到了一个可以多角色进行协作的数据库工具—— Bytebase. 于是我和我的同事们也就在做核酸和做饭的间隙开始试用Bytebase，在这里和大家分享一下试用过程。
Bytebase 支持多种角色，登陆并加入自己的 Workspace 之后可以在 Settings > Members 当中看到自己的角色，角色由 Owner 进行分配，不同的角色具有不同的权限。除去我自己的 DBA 这一角色外，还有 Developer 的角色，几种角色看到的信息和权限是不同的。
在实际进行数据库 Instance 配置之前，首先要进行环境配置，具体需要几个环境视实际需要而定。对我来讲我需要一个开发者环境 (Dev) 以及一个生产环境 (Prod)。在创造新环境时以及环境配置完成之后都可以选择自己理想的 Approval Policy，既可以要求 schema 变更必须经过手动通过才能进行，也可以选择跳过手动变更，直接自动实施。同时在环境配置中也可以选择进行数据库备份的频次（每周一备份 / 每日一备份 / 不进行规定期限的备份）。
接下来就是在要把人力资源的 employee 数据库 Instance 导入到 Bytebase 中，在之前设置的两个环境中各自进行配置。我们公司用的是 MySQL 数据库，不过 Bytebase 同时也支持PostgreSQL、RiDB、Snowflake以及ClickHouse，还是蛮多样的。 比较喜欢的一点是，在每个 Instance 之下除去管理者 (Admin) 之外还可以设置“只读用户”—— aka. Read Only User，对于数据库的安全来说还是相当重要的功能。
接下来创建 Employee 这个 Project，选择 New DB与前一步设置好的两个 Instance 进行连接，于是我们拥有了两个环境下的 employee database。在 Project 当中有且仅有 Owner 和 Developer 两个角色，Owner 可以进行角色的分配和更改，Developer 这里只能看到自己被分配到了什么角色。
在同一个 Project 中进行好角色配之后，成员互相之间可以同步数据库 Schema，在界面上直观地看到Project 中进行过的活动以及迁移历史。通过 Transfer in DB 这一功能还可以将其他项目中的数据库迁移进来。
我们现在刚刚开始使用 Bytebase，Project 数目还不算多，所以还不难查找，但如果之后 Project 数目多了那么 k-bar 就派上用场了。Bytebase 的 k-bar既可以通过在界面左端直接通过点击进行搜索，也可以通过快捷键 command + k 召唤出来。 可以看到在 k-bar 里可以进行对项目或者功能的检索，有一些较为常用的功能也可以直接通过提示的快捷键进行显示（一定要在 k-bar 关闭的情况下才可以用快捷键调取）。同时，如果怕比较常用的 Project 消失在茫茫人海中，也可以在 Project > Project_Name 的右边点亮那颗星星，对项目进行 Bookmark。
今天把 Project 建起来了，初次使用每点击一个按键都会跳出指引提示，整个用下来还是挺顺手的。不过目前只探索了 Bytebase 的一些初级功能，居委会喊我下去做核酸了，等过两天我再研究一下其他的功能。
TBC.