初创公司应该如何做好持续集成和部署选读.docxVIP

初创公司应该如何做好持续集成和部署？前言持续集成和部署是每一个互联网开发团队都必须要面对的问题，特别是在初创公司，由于业务和技术团队快速增长，技术积累较弱，所以一个高效的，可持续的运维规范尤为重要。最近一段时间，一直在梳理项目开发流程以及自动化测试和部署规范，作为一个总结和大家分享，希望有所帮助。高效可持续的运维环境需要合理的规范作为支撑：应用管理规范权限管理规范配置变更规范发布策略规范日志运维规范持续集成部署实战(该内容将在后续文章中进行讨论，本次不展开)一、应用管理规范1. 应用版本化可以使用SVN、Git对代码进行版本控制。建议使用Git(如：GitLab)，并使用Git Group命名规范：大原则为根据产品域名区分，或者根据前后端业务模块进行分组(小写字母命名，横杠[-]作为连接字符)。举例：MAKA官网 http://www.maka.im 对应的Git仓库Group为official，按照功能模块分组，商城前端对应的Git仓库Group为store。项目名命名规范：??? 全部用小写字母??? 横杠[-]作为连接字符??? 命名规则：[产品名称]-[项目类型]-[自定义名称]举例：official-store-customer。实践建议：在创建项目仓库时就要权衡前后端或者大的功能模块的拆分，保持低耦合度。2.合理的分支策略常用的Git工作流总结如下：第一种：集中式工作流，很多公司使用SVN，对Git的使用并不熟悉。如果迁移至Git之后，可以考虑集中式工作流进行开发，即代码库只有 master 一个分支，所有开发者只有本地 master 和远端 master 分支。这种方式使用简单，但无法充分发挥git的优势。第二种：功能分支工作流，与上一种不同的地方在于，除了 master 分支以外还有功能分支。日常开发在功能分支，提测集成时提交Merge Requests(在Bitbucket中是Pull Request)。开发者可以在这个时候进行讨论、审核代码，同意后可以合并至 master 分支，未同意则可以让开发者修改后重新提交或者选择关闭该MR。举例： third-party-login-feature?第三种：Gitflow工作流，两个主干分支 master(正式发布分支)和 develop(功能集成分支)。开发者应基于 develop 分支创建 feature 功能分支，用于开发，开发完成后提交merge requests请求合并进 develop 分支。此时若到了发布窗口，基于此时的 develop 分支创建发布分支 release 用于测试 → 预发布 → 发布，以避免影响 develop 分支的正常集成、合并功能分支；release 分支不再有新的功能合并进来，一旦创建只用于 bug 修复并将修复 cherry-pick 到develop分支；发布完成后，release 分支合并进 master 并分配版本号、打tag，用于存放发布历史。Gitflow工作流方式适用于大型项目第四种：Forking工作流，开发者 fork 官方的 repo 到自己的账号空间，对于官方分支只有只读权限，开发者通过pull request 提交给官方审核是否合并进代码库；开发者通过同步上游官方的 repo 来使用其他人的代码，分支策略可参考上述三种工作流，适合开源项目。针对创业公司参与同一个项目的开发者并不多，过于复杂的分支策略并不能带来便利，可以参考leancloud的分支模式，根据团队的使用情况进行调整。介绍下我们当前使用的分支策略：master：主干分支，用作日常开发的基线；userA：开发者A日常开发所在分支；release-201603091106： master分支集成测试完成后，构建到预发布环境时自动创建 release-201603091106 用于发布。hotfix-201603091106：基于当前发布之后的 release-201603091106 分支用于修复bug，通过提交merge requests 方式合并进 release-201603091106，并将修复 cherry-pick 到master分支。日常开发在userA分支操作，然后提交merge requests 请求合并至 master 分支，本地通过git fetch origin master，然后在userA分支git rebase origin/master 将 master 最新 commit 合并到本地userA分支从而形成闭环开发。3.关于代码审核三剑客GitLab + Jenkins + Gerrit。Gerrit作为创业公司代码审核工具略显复杂，不足够敏捷，建议使用GitLab的 Merge Requests 或者Github