您可以与初级程序员一起进行连续部署吗？

有一瞬间，您开始了解到，在微服务体系结构中，要等一周一次部署所有微服务以确保所有功能都能正常工作，要比严格执行api版本控制，编写大量自动文档更令人恐惧。测试（每个测试有点：单元和探索，集成），并在阶段测试通过提交后就自动将其部署到生产中。

现在，只要您记得编写测试，在提交之前测试您的更改，知道如何使用API​​版本控制，并且您不会将数据库删除在部署时执行的增量数据库更新脚本中，这似乎是个好主意。不是大问题，因为它应该在舞台上失败）。

但是，与初级程序员一起这样做是否可行？也许我将必须实现请求请求模式。这会使它不像连续部署（这是我的猜测）吗？

我希望这不是基于观点的，我可以指望您分享您的经验，谢谢。

请注意，我不是在问CI还是在持续交付。我们已经有了。我们现在正在尝试使其连续部署，这意味着在代码签入之后将其全部投入生产。

为什么不？无论您是否使用连续部署，您描述的任何事情都会成为问题。看来，问题在于您担心下辈子会犯一个灾难性的错误。那个错误将在任何人发现之前迅速投入生产。

这就是为什么您要进行代码审查并进行测试。在任何东西合并到您的master分支并发布之前，要求其他一些初级人员（以便他们获得经验）和高级开发人员（使用他们的专业知识来使代码更好）对代码进行审查。每个人都应该寻找这些灾难性的错误。它应该阻止他们。如果不是这样，您可能需要在登台环境上进行一些更好的QA /测试（如果代码审查遗漏了这些内容，则可能需要一些更好的开发人员）。

如果您有一套很好的自动化测试，那么连续部署将很好地工作。

初级开发人员可以为自己的任务感到兴奋，而看不到他们会破坏周围的事物。您可以通过一些自动化解决此问题。设置一个将一直运行测试的构建服务器，并为他们提供类似CatLight build notifier的工具。当他们遇到麻烦时，它将为他们提供快速清晰的反馈。

他们将在发生小问题时予以解决，并保持您的连续交付运行。

学习良好习惯的唯一方法是练习习惯，因此，初级开发人员还可以练习持续部署。您可能需要考虑将一些步骤添加到管道中，以执行诸如检查测试覆盖率并可能运行静态代码分析之类的操作，如果测试覆盖率不够高，则使构建失败。这样可以确保初级开发人员在完成某些事情之前就了解他们的期望。

您不仅可以与初级开发人员一起执行此操作，而且您也需要这样做。首先，否则会降低软件质量，其次，这有助于初级开发人员学习良好的软件开发技能。

打个比方：您是否希望您的医生不会因为他担心年轻的学徒制错误而尽其所能行医？医生如何处理潜在的损害？

根据过去在许多无人监督的初级开发人员手中多年发展而来的“泥泞大球”代码库的经验，我想指出一下当您不与那些开发人员一起实践CI 时会发生什么。

编辑/更新：根据RubberDuck的评论；该答案假定您的集成合并目标是开发分支，而不是评估或发布分支。

• 显然，需要对发布和实时部署的代码进行更多控制；如果没有单独的生产分支，则有必要考虑更改分支/合并策略，以便与主发布分支一起运行主开发分支（用于集成测试，而不用于发布）。这样就保留了CI的所有优势，并且可以频繁合并，而不会冒破坏生产代码的风险。

1.初级开发人员与同事或主管沟通的可能性较小

持续集成不仅仅是合并代码的问题，而是在某个时间点上，开发人员被迫与其他利益相关者进行交互。

沟通很重要，并且不希望过于笼统，它往往是一种博学的技能，对于没有经验的开发人员而言，它比那些习惯于在团队环境中工作的开发者更不自然。

如果您允许初级开发人员坐在小隔间里，在不要求频繁报告/审阅的情况下猛烈抨击代码，那么他们更有可能完全避免交流。

2.他们正在生成的代码可能需要更严格的审查

您是否曾经审查过如此糟糕的东西，以至于希望您早点拿起它并阻止它被编写？这经常发生。

您不能阻止编写错误的代码，但是可以限制浪费的时间。如果您承诺进行频繁的审核和合并，则可以将浪费时间的范围最小化。

最坏的情况是，您可能将一个初级开发人员留在自己的微型项目上几个星期，而当他们终于准备好进行代码审查时，根本没有足够的时间让他们把整个混乱离开，然后从头开始。

许多项目之所以成为一个泥潭，仅仅是因为在没有人注意的时候写了一大堆不良代码，直到为时已晚。

3.您应该不太确定初级开发人员或其他新团队成员已了解要求

有时，开发人员可能会为错误的问题提供完美的解决方案。这个问题很可悲，因为它通常归结为简单的误解，如果只有某个人在此过程中早些时候提出了正确的问题，就很容易避免。

同样，这是一个问题，很可能会影响没有经验的开发人员，这些开发人员更可能从表面上接受“不好的”需求，而不是回退并质疑该需求的智慧。

4.他们可能不太熟悉通用模式，现有代码的架构以及众所周知的工具和解决方案

有时，开发人员不必要地花费全部时间来重新设计轮子，只是因为他们不知道甚至存在更好的解决方案。否则，他们可能会花费数天的时间试图将一个方形钉钉入一个圆孔中，而没有意识到自己在做错什么。

同样，没有经验的开发人员更可能发生这种情况，解决此问题的最佳方法是确保定期进行审查。

5.两次代码提交/合并之间的时间间隔过长，使缺陷难以识别和修复

在将价值几周的代码更改合并到master分支中后，如果立即出现错误，则识别哪个更改可能导致该错误的挑战就变得更加困难。

显然，您的总体分支策略也在这里发挥作用；理想情况下，所有开发人员要么在自己的分支中工作，要么在功能分支中（或同时在两个方面）工作，并且永远不要直接在主/主干之外工作。

我见过这样的情况：整个团队都同时直接在主/主干中工作，这对于CI来说是一个糟糕的环境，但是幸运的是，使每个人脱离主/主干的解决方案通常为单个工作提供了足够的稳定性。物品/门票/等

对于任何开发人员来说，中断 master / trunk分支始终是“确定”的，这应理解到合并应该在这样的规则基础上进行，应该更快地识别出更改和缺陷，并因此也可以更快地解决。最严重的缺陷通常是几个月甚至几年都未被发现的缺陷。

综上所述; 持续集成/持续部署的主要优点是：

• 团队之间的沟通得以改善
• 代码质量通常保持较高的标准
• 需求被遗漏或误解的可能性较小
• 应该更快地发现架构和设计问题，
• 缺陷更可能在早期被发现并修复

因此，如果您不与初级开发人员一起练习CI，那么您将承受很多重大的不必要风险，因为这些是团队中比其他人更需要的风险。

是的，您可以与初级开发人员一起练习CI。在当前的发展环境下，这将是愚蠢的。能够推送回购然后将其自动合并到登台代码中并在Travis（或Bamboo，Pipelines等...）中实时观看所有代码，这是非常有用的！

带上您的DevOps家伙，让他与他们一起完成整个过程，再加上一个高级待命的开发人员，以监视事物并将其与他们的代码审阅联系起来（您这样做是对的吗？）

如果您担心哪些代码会通过，那将不在CI上，也不会在初级用户上：它在您身上。

因此，帮助他们变得更好，并习惯于更快地部署阶段/产品代码。从长远来看，你会感谢自己的。