作为我们的交付团队，仅使用我们自己的资源，在CI / CD下重命名我们的系统。
工程师团队不断承受压力：您需要以有价值的产品形式提供新功能，同时不断缩短周期时间 。 通常，专家没有抓住最新工具。 在我们唯一的DevOps生命周期应用程序GitLab中内置了持续集成和交付（CI / CD），现在我们与其他团队一起迁移到Kubernetes，以进一步缩短周期时间。 但是，对于CI / CD以及最终的Kubernetes，我们采用了一种非常不寻常的方式。 交付团队将我们切换到GitLab.com的连续交付，这使旧系统紧张，然后才完全切换到Kubernetes。
我们如何发布CI / CD之前的发行版
在2019年8月7日至9月27日之间，庞大的GitLab社区和我们的团队成员平均每天达到55次提交 -这些是我们产品的不断迭代以创建新功能。 但是在掌握持续交付之前，我们从每个月的7日开始冻结新功能：此时，我们的工程师将注意力从开发新功能转移到调试，转向准备在每月22日稳定发布即将发布的版本。
通过引入严格的截止日期，我们向开发人员灌输了一种行为，可以帮助他们最终专注于特定日期，而不是专注于准备情况。
“ ...开发人员从7月7日开始跳舞，因为他们查看了日历并思考：好了，还有时间，一周的7日，然后在6日的午夜，他们疯狂地合并了，” Marine说交付团队的首席技术官Jankowski 。 “他们知道，如果他们超过了最后期限，他们将不得不再等一个月，而且如果他们能及时做到这一点，他们将有两个更好的星期来进行调试。”
自从GitLab.com成立以来，冻结新功能的时间一直被用作稳定时间，” Marine解释道。
但是，用户数量在增长，并且对新功能的需求迫使我们加快了开发速度。 稳定期减慢了周期，并极大地延迟了向功能调试，回归和交付功能的过渡-无论是向Gitlab.com上的用户还是个人客户。
“在某些情况下，[冻结新功能]甚至引发了平台的不稳定性-由于最高优先级的修补程序没有及时到达客户端，” Marine说。 -“通过切换到CI / CD，我们可以提供新产品并更快地调试它们。”
在我们成立交付团队以将GitLab.com迁移到连续交付 （最终到Kubernetes）之前，我们依赖发布经理 。 这是准备新版本的开发人员所拥有的过渡职位。 我们已经对该过程进行了5年以上的迭代 ，但是发布经理已经创建了一个知识库，并使其或多或少地实现了自动化。
但是，该方法实际上是无效的，因为部署计划和发布准备工作浮动：从半天到几天，这是由于在该过程中积累了手动执行的任务 。
“发布经理收到了固定的任务清单，截止日期，并一遍又一遍地重复上述步骤，直到在GitLab.com上获得完全准备好且稳定的发布为止，” Marine说。 从最一般的意义上讲，发布管理器要求以下内容：
- 手动同步组成GitLab的许多存储库。
- 确保手动创建的Git分支中包含正确的版本。
- 当发行版收到标签时，将测试和生产环境手动部署到GitLab.com。
- 确保一切正常，并为单个用户手动发布软件包。
在致力于该主题的GitLab承诺期间在布鲁克林的一次演讲中 ，Marine分享了2018年的观察结果：在发布之前的两周内，交付团队花费了60％的时间与部署进行交互，另外26％的时间用于手动和半手动任务，例如撰写评论每月发布。
在转为连续交付之前的2018年观察结果：这是交付团队在发布前2周花费时间的方式。
“从总体上讲，即发布前两周，即14天，团队只做了它盯着监视器的东西，看着油漆是如何变干的，” Marine说。
但是，要承担其中的86％（部署为60％+手动任务为26％），交付团队将解决许多问题：
- 新版本没有延迟。
- 可重复且更快的部署，而无需停机。
- 更多的时间将GitLab.com迁移到Kubernetes。
- 为组织连续交付做准备的更多自由。
尽管CD仅在GitLab.com上可用，但我们的个人客户也可以从我们的过渡中受益。 现在，不受CI测试影响的所有内容都将在环境中自动和手动进行测试-进入GitLab.com。 进入GitLab.com并需要调试的所有内容都将在几个小时内完成调试。 因此，针对个人客户的最终版本将是干净的。
从冻结到CD的过渡是一个时间问题，随着我们功能的增长，Marina领导的工程师团队似乎观察到了这一过渡：“成立交付团队的唯一目的是将公司转移到CD模型，同时转移公司到Kubernetes平台，以促进扩展并加快周期。”
大多数代替GitLab的公司将开始向CI / CD和Kubernetes过渡，首先将新技术集成到其工作流程中，并在此过程中纠正开发过程。 我们选择了另一种方法。
迁移到Kubernetes不仅需要改变生产系统，还需要改变开发方法。 Kubernetes提供了易于使用且无需额外投资的某些功能。 但是为了真正受益于Kubernetes提供的免费功能，您需要某种CI / CD。
交付团队接受了这一点：为了促进向Kubernetes进行连续交付的过渡，我们的工程师应该已经专注于CI / CD，这意味着增强了质量控制（QA）和更严格的功能计划。 然后，我们的交付团队做出了一个令人沮丧的决定 ：使用现有工具构建CD系统并重组GitLab.com应用程序的基础结构-而不是立即掌握新的CD工具和技术。
“这个想法很简单，” Marin说，“我们使用可用的工具 ，使大多数手动任务自动化，并在负载下测试整个静态系统。如果静态系统可以承受，我们将进行动态测试。”
这种方法提供了两个主要好处：
首先 ，我们已经确定了我们方法中的所有弱点，并通过使用CI进行自动化来解决了这些弱点，从而使我们的应用程序变得越来越强大，并且向Kubernetes过渡的成功变得更加真实。
其次 ，在CD上建立了一个工程师团队，我们在GitLab工程师的心中实施了该工具，他们习惯于每周进行部署并等待，有时会整天（因为它们影响合并），这是真正的文化转变。
“自从我们掌握CI / CD以来，我们的开发人员就开始以一种新的方式来理解要完成的工作，” Marine说。
在引入CI / CD之前，审核完成后，就认为更改已准备就绪。 这样就省去了在各种环境中的部署，这非常耗时。 如今，部署已在几个小时内交付完毕，因此没有理由不确认所做的更改是否可以在测试和生产环境中正常运行。
部署Kubernetes审查应用程序使开发人员可以实时地实时运行质量检查，并且使用功能标记进行逐步交付还可以加快开发速度。
“从CD的第一步开始，开发人员就必须对每个自动化质量控制做出响应，并在生产和测试环境中以新的级别执行手动确认。此外，开发人员可以在一天之内对生产环境进行更改。而更早的时间则需要几天（甚至几周）。”
使用CD，您可以更频繁地执行代码质量检查。 而且由于使用我们的CI / CD系统，代码的更改是全天候进行的，因此开发人员可以按需轮流处理实时出现的任何非标准问题，因为大大缩短了“潜伏期”。
我们的新方法
实施CI / CD系统后 ， 我们使流程的90％ 自动化了。 其余的10％需要人工干预-需要在具有访问权的许多人之间进行协调。
海军陆战队说：“我们正在逐步减少这10％的排放量，因此我们只需要批准该版本的发布即可。” 在当前迭代中，CI / CD流程如下 ：
- CI自动在审阅者和开发者批准的合并请求中搜索特定标签。
- CI自动同步所需的存储库，同时创建必要的Git分支，标签，还包括我们要交付的正确发行版本。
- 构建完成后，程序包将自动部署到测试环境。
- 执行自动质量检查，如果一切顺利，则将部署交付给生产环境中的一小部分用户。
- 同时，开发人员手动执行不同级别的质量控制-以确保新功能可以正常工作。
- 如果在手动确认期间发现高优先级问题，则部署将停止。
- 完成上一步后，交付团队成员将为所有GitLab.com用户启动部署交付。
- 然后，基于在GitLab.com上启动的最新生产部署，创建单个客户版本。
与任何其他工程团队一样，扩展规模对我们来说是真正的挑战。 但是，技术人员面临的最大挑战之一是确保质量控制覆盖所有内容，但是对于像GitLab.com这样的大型项目而言，这是一项艰巨的工作。 而且，您还需要确保有足够的监视和通知，以便该项目不能仅按预定义的规则运行。
对我们来说，第二个主要挑战是GitLab.com系统的复杂性，以及在此过程中将更改直接转移给所有工程团队的问题。 海军陆战队说：“打破多年来建立的过程和习惯绝非易事。”
结果
GitLab已经从切换到CI / CD获得了很多好处。
对2019年的观察和评估显示，在发布前的14天中，交付团队将82％的时间花在了更高的生产力上：释放了它来处理其他重要任务。
对2019年的观察表明，由于向CD过渡，在相同的两周内，开发人员腾出了很多这样宝贵的时间。
通过使手动工作自动化，交付团队最终转向更改GitLab.com的基础架构，以改善对开发速度和用户流量以及向Kubernetes迁移的支持。
“而且，正如我已经说过的，这一切都没有Kubernetes。所有事情都是在旧的前身系统上完成的，” Marine对布鲁克林GitLab Commit的客人说。 -“但是我们赢了时间，所以现在我的团队密切参与了迁移。但是，最大的变化之一恰恰是组织开发的习惯。”
过渡后的结果非常重要。 如果在2019年5月的旧系统上，团队交付了7个部署，那么在2019年8月，这一数字增加到35。这不是极限：这个数字将大大增加-现在，团队每天交付许多部署。
“我们只是将注册表服务迁移到Kubernetes，如果您使用GitLab.com上的容器注册表 ，则所有请求都将在Kubernetes平台上执行，” Marine说。 -“ GitLab是一个多组件系统，我们将继续隔离和转移其他服务。”
每个新版本均包含新的CI / CD功能。 例如，在版本12.3中，我们扩展了GitLab容器注册表-允许用户使用CI / CD并将图像/标签收集并嵌入到自己的项目中 。 还有其他令人兴奋的新创新。
还要将系统转移到连续交付吗？
Marin建议刚开始使用CD的公司从拥有的产品开始。
Marine说：“对我而言，坐下来等待迁移到新平台会损害自己。” “大多数系统可以以某种方式进行更改，并且可以在不迁移到全新系统的情况下加快处理周期。加快开发/发布周期可以极大地提高系统中每个工程师的效率，并可以腾出更多时间迁移到Kubernetes等新平台。”
如果您对下一步有什么好奇，请查看此激动人心的CI / CD新功能的详细摘要，这些新功能正在等待中-从版本12.4开始。
想念布鲁克林的GitLab提交吗？
如果您不能在我们过渡到Kubernetes的背景下参加Marina的演讲，请观看下面的完整视频，并加入我们于10月9日在伦敦举行的欧洲GitLab提交 。