……并偶然建立了DevOps。
回顾为公司开发人员改善和优化工作环境的三年，我们学到了很多东西。 从那时起，很多事情都改变了我们的观念。 到目前为止发生了什么。
阶段1：实际状态分析
🤕 痛苦
无论采用哪种技术或IT项目经理，您都在以应用程序开发人员的身份从事软件开发部门的工作吗？
当然，您已经从客户或经理那里听到了以下一些句子。
“我们需要尽快使用最新版本的App进行测试。”
“交付的版本已有数周之久。我们可以尽快对其进行更新吗？” ”
“ 应用程序下载链接已死。 ”
“ 需要构建哪个版本？ 我们需要提供什么版本？ ”
“ 无法安装该应用程序，证书无效。”
“ 有空余时间上载新版本的人吗？ ”
短暂休息一下，感受一下这些陈述触发的个人情感。
这是纯粹的痛苦吗？
如果不是，您可以在这里停止阅读。
Vision愿景
经常面对这些声明的开发人员会想到什么？
只是自动消除痛苦的特殊愿望。 我们的技术爱好者喜欢在任何地方实现自动化，因为这是简化日常任务的一种态度-为什么不通过自动化基础流程来解决这些难题。
在一个完美的世界里，我会在早晨醒来。 买我的咖啡，开始开发新功能，修复昨天测试版本中的一些错误，再买一杯咖啡……然后，通过观看要自动构建和交付的应用程序（准备进行测试）来结束我的一天。 每个人都会收到有关新版本的通知-无需再写一条松弛消息。
那会不会使我们的生活更加舒适？ 在一个完美的世界里，我会在早晨醒来。 买我的咖啡，开始开发新功能，修复昨天测试版本中的一些错误，再买一杯咖啡……然后，通过观看要自动构建和交付的应用程序（准备进行测试）来结束我的一天。 每个人都会收到有关新版本的通知-无需再写一条松弛消息。
🔎 起点
那时，我们已经有一个构建服务器（ 称为Jenkins ）。 它很少使用。 在您作为开发人员的日常业务中，有时会遇到这种Jenkins并为之打断。Jenkins的推出是为了让每个人都能够创建应用程序构件，而无需在开发机器上进行操作。
构建应用程序
偶尔会手动触发构建，因为是时候再次向客户交付新的应用版本。 这样就存在许多障碍。 有时，您甚至没有被分配到该应用程序的基础开发项目，而是只有一个拥有一点闲暇时间和幸运的是关于这个Jenkins怪物的专有技术的人。 在为服务器上的项目找到正确的“构建作业”并解决了许多构建问题之后，通常会在经过数小时的猜测，尝试和错误之后，最终生成了一个构建工件。
下载工件
成功构建后，看到绿灯闪烁，您的任务是将正确的工件下载到计算机上以完成以下任务。
将其上传到某处交付
您的下一个任务是找到有关此项目的交付过程的一些信息。 在哪里上传呢？ 访问上载版本的凭据是什么？
在某处找到了一个知道该工件上传到哪里并且幸运地拥有正确凭据的人之后，您最终得到了一个上传的应用程序，并最终向客户发送了通知。
开心的我！ 现在：返回工作以开发当前分配的项目。
结论
交付一个版本是运气的问题，因为它能找到正确的方法来穿越各种障碍。 这不可能是最后阶段。 利用我们的构建基础设施，我们还有更多的可能性吗？
第二阶段：实施
📦持续整合
我们开始深入研究Repository Manager（GitLab）的文档，并检查是否可以轻松集成到Jenkins Server，如果代码已更新，则可以触发新的构建。 我们发现了有关Webhook和提交触发器的信息，并在两端进行了设置。
结论
我们做到了！ 通过一些简单的步骤，我们在不知情的情况下实现了持续集成 ，并完成了我们轨道上的第一个检查点。 我们现在已经成为CI炒作火车的一部分！
对于我们的项目而言，拥有CI的优势显而易见。 每次推送代码后，如果应用程序仍在沙盒环境中构建，而不仅仅是在我们自己的本地环境中构建，我们都会有好（或坏）的感觉。 预计在建设初期会出现问题，从而使以后的生活压力减轻。
🚀 持续交付
快进到几个月后……，我们在每个新项目以及少数现有项目中建立了持续集成，并创建了与詹金斯打交道的第一批最佳实践。 应用交付阶段之前的紧张日子减少了。 不再需要在周五下午手动触发Jenkins构建，而用手指交叉的绿色交通信号灯将显示成功构建。 星期五下午在我们的Jenkins上已经存在一个构建工件，只是在等待将其上传到文件服务器，并与客户共享该文件。
我们问我们是否可以进入将上传文件自动上传到ftp服务器的下一阶段，并向完成此工作的Jenkins Build Script添加了几行代码。
结论
我们是否刚刚到达连续交付的最后阶段？ 是的，我们做到了！ （至少我们认为，当时我们做到了）
现在，在推送到我们的仓库后，并成功将构建上传到文件服务器之后，就构建了该应用程序。 大！
♻️重构
我们喜欢看这种设置AUTOMA 摹陆续ically上传一个版本。 我们引入了适当的版本控制，以使服务器上的文件不会被覆盖，并引入了手动过程，定期在服务器上做家务并删除旧应用。
SCM的Jenkins管道脚本
但是，一旦将其引入其他项目，我们就会看到坏事的发生。 Jenkins脚本被复制并粘贴。 从一开始就一直没有挑战，直到现在都可以使用-但是现在我们突然在脚本中有了一个逻辑，该逻辑足够通用，可以在作业之间共享……上传文件的简单逻辑。
我们开始评估在不同作业之间共享脚本的最佳实践，并接触了从源代码存储库中提取脚本的巧妙方法。 詹金斯（Jenkins）允许为每个作业管道脚本使用此选项。 我们继续为所有管道脚本创建git存储库。 在开始在此仓库中创建所有新作业脚本的过程中，我们还从普通的bash脚本切换到了Groovy脚本，并在单独的utils脚本中提取了可重复使用的代码，然后将其导入到特定于管道的文件中。
介绍HockeyApp（现为AppCenter）
我们还搜索了比ftp服务器更方便的方法来为iOS，Android和Windows平台提供应用下载。 HockeyApp（现在为AppCenter）是解决方案。 HockeyApp是一个平台，提供了一种轻松的方法来管理App二进制文件并将其分发给Beta Tester。 这次转换使我们能够管理不同的测试人员组（内部和外部），并加快了测试周期，从而显着提高了每个项目的质量。
📬通知
在重构阶段和不同部门的大量反馈之后，我们决定改进新版本的通知流程。 幸运的是，我们同时改善了内部沟通流程，并引入了松弛作为主要的沟通工具。 Slack非常适合我们的情况。 我们检查了与Jenkins的集成，并迅速找到了一种通过松弛通知来丰富我们的管道脚本的方法。 第一步，我们向项目松弛通道发送了有关发行或构建失败的通知。 这导致那里正在进行的讨论中断。 因此，我们决定为每个拥有CD管道的项目增加一个通知渠道，并邀请所有项目成员加入这些渠道。
结论
通过添加通知，我们大大提高了项目的透明度。 现在，每个项目成员都时刻了解项目状态。
我们设法为每个项目参与者找到一个合适的解决方案，该解决方案解决了许多手动步骤，而信息流却没有减少。
阶段3：观察和改善
O DevOps
我们在不知不觉中在开发运营领域做了很多工作。 那时我们刚开始的时候，DevOps的表达没有广泛传播，或者至少没有传播到我们身边，我们花了一些时间才意识到DevOps对我们意味着什么。 至少我们现在有一个术语来描述我们的任务，这对于内部交流非常方便。
至少对于非技术人员来说，解释术语DevOps和工作领域权利确实是一项挑战。 定义从“我是文本文件工程师”到“我使无聊的东西……充满魔力”自动化。
（ https://www.reddit.com/r/devops/comments/awx6d7/can_anyone_describe_our_profession_to_nontech/ ）
📈持续改进
众所周知，谁不再是更好的人就不再是好人。 因此，我们的目标是围绕“持续交付管道”迭代地改进我们的流程。
工作小组
我们引入了一个由不同技术栈的专家组成的DevOps工作组，以获取更多反馈，并提高公司在DevOps方面的知识共享以及其可能性和优势。 作为工件，我们正在为不同的技术堆栈生成最佳实践。 该工作组正在逐步发展成为内部服务提供商，以解决有关改进开发和发布周期的所有主题。
最佳实践
我们介绍了针对不同构建目标和平台的通用作业脚本和最佳实践。 通过选择现有的作业配置并更改参数以适合新项目，这允许在短时间内为新项目创建新管道。
自动化样式检查与测试
我们集成了自动化样式检查和测试，以提高我们的代码质量，并在项目成员之间建立总体上对代码质量的共识，从而进一步完善了完成的定义。 引发了有关该主题的许多讨论。
自动生成代码文档
我们创建了脚本来自动生成内部库的代码文档。 它本身就是一个完整的主题，包含许多讨论以及尝试和错误迭代。 我将在另一篇文章中回顾这个主题。
每晚构建
我们还引入了自动夜间构建，以尽早预测构建管道中的基础架构故障，第三方集成问题以及其他其他未导致代码提交中断的根本原因的错误。 这对于已经推出并且没有正在进行的开发冲刺的项目是必要的，因此没有定期进行构建。
每天早晨看到成功完成所有正在进行的项目的感觉真是太神奇了，并开始您的工作日。
🛤简历（tl; dr）
阶段1：实际状态分析
我们从开发人员的角度分析了应用程序开发阶段的主要痛点，并尝试逐步解决它们。
第二阶段：实施
我们定制了一些现有工具，引入了一些最佳实践和流程，并设法在三年的时间内建立了一个工作组。
阶段3：观察和改善
我们了解到，我们正在做的事情有一个术语-DevOps。 我们仍在改进我们在第二阶段中实现的功能，以适应新技术，平台和流程。
我们将DevOps视为改善开发人员工作环境的主要工具。 同时提高项目透明度并让开发人员专注于基本要素，从而尽可能减少干扰。 另外免费获得应用程序质量的提高。
持续交付实施通过定期的项目审查和冲刺，非常适合我们的敏捷开发方法。
