Skip to content

DevOps

Dev Envrionment As Code - Devbox 使用指南

TLDR

本文介绍了使用 devbox, 以 开发环境即代码 的方式搭建了团队本地开发环境, 同时介绍了一些团队中基于 devbox 实践经验, 有效帮助团队提高开发效率

  1. 集成 pre-commit, 自动初始化
  2. 集成 co-author 脚本, 自动添加pair
  3. 集成 conventional-commit, 规范提交信息
  4. 为团队定制化指令, 提供快捷方式

挑战

切换项目是一个 TWer 需要面对的挑战, 当做为一个项目新人, 比较重要的一项工作就是下载代码, 安装依赖, 使代码能正确在本地启动并运行.

常常需要以下几个步骤

  1. 下载应用的运行环境或编译环境, 如JDK, NodeJs, ruby, python, gcc 或 rustup, 并且版本需要一致
  2. 下载应用包管理程序, yarn, gradle/maven, sbt, cargo, bundler, 并保证版本一致
  3. 设置构建/运行程序必要环境变量, 比如企业内部maven repository地址/token, npm retristry 地址/Token
  4. 下载安装 "开发/部署/管理" 应用的脚本/命令, 如 pre-commit, tf-lint, kubectl, awscli等
  5. 手动运行一些初始化脚本, 如 pre-commit init 安装 git-hooks
  6. 学习使用一些项目定制好的脚本, 可以快速启动项目

通常项目代码里的 README.md 会提供详细的运行文档, 新人根据文档手动执行各种命令, 完成安装运行; 如果遇到问题, 找人提供对应的指导. 这种模式存在几个问题:

  1. 文档更新滞后 - 大多数时候, 随着项目的演进, 文档大部分时候总是滞后并缺少维护. 最终都是新人花很多的时间进行定位
  2. 运行环境不一致 - 项目中成员的机器可能都装了不同版本的 JVM, NodeJs, ruby, python 作为默认开发环境, 各个版本五花八门. 导致应用在某些特定版本的开发环境上表现不一致. 当在不同项目中切换时, 经常需要引入不同虚拟机管理工具 如 NVM, RVM, asdf, SDKMan
  3. 手动安装的不可重复性 - 手动安装的命令/程序不可靠,
    • 如命令版本太新/太旧导致, 导致不能运行
    • 如经常会漏掉执行一些初始化脚本

如何优雅地提交(1) - pre-commit

TLDR

本文介绍了一个工具 pre-commit是用来管理 git-hooks. 同时推荐几个常用插件, 并总结了一些项目中的最佳实践.

正文

GIT 是一个非常流量的版本工具. 在程序员的日常开发中, GIT 帮助我们非常有效率地管理代码的历史几率. 通过 GIT, 开发者可以使用各种命令 commit, push, merge, 来管理源代码, 和其他开发者一起协作来开发应用.

在日常开发中, 我们会经常使用 Git Hooks 来进行提交前(pre-commit, pre-push)检查, 来保证推到远程的代码符合规范, 并且测试通过, 以提早发现问题, 从而不阻塞部署流水线.

然而在每次克隆(clone)新代码库时, Git Hooks 都需要手动初始化一遍, 比如前端开发会重使用 husky 来管理和安装 Git Hooks. 而像一些由 Gradle 构建的 Java 项目, 会在构建脚本 build.gradle 中加入一些如下初始化代码, 帮助自动安装 Git Hooks脚本. 如下所示

task("addPreCommitGitHookOnBuild") {
    exec {
        commandLine("cp", "./.scripts/pre-commit", "./.git/hooks")
    }
    println("Added Pre Commit Git Hook Script.")
}
build.dependsOn addPreCommitGitHookOnBuild

pre-commit 正是一个开源的专注于管理 Git Hooks 的框架, 虽然他是由 python 编写的, 但他并不像 husky 一样, 仅仅只局限于一种语言, 他对多种编程语言做了支持, 并提供了插件机制, 所以他可以是通用的.