我发布了9月举行的
第一批报告中的第二份报告。 上一次您可以阅读（并看到）有关
使用Consul扩展 BIT.GAMES的Ivan Bubnov的
有状态服务的信息，今天我们将讨论CICD。 更准确地说，我们的系统管理员Egor Panov将对此进行介绍，他负责Pixonic中基础结构和服务的可用性。 下切-解码性能。
首先，游戏产业的风险更大-您永远不知道到底会出现什么东西会渗入玩家的内心。 因此，我们创建了许多原型。 当然，我们在棍棒，绳索和其他简易材料的膝盖上创建原型。
用这种方法看来，做一些可以得到支持的事情通常是不可能的。 但是即使在这个阶段，我们仍然坚持。 我们坚持三个支柱：
- 优秀的测试人员专业知识；
- 与他们密切互动；
- 我们给出测试的时间。
因此，如果我们不建立部署或CI（持续集成）之类的流程，那么我们迟早会得出结论，测试持续时间将一直在增加。 而且，我们要么做慢一切，失去市场，要么在每次部署中都爆发式增长。
但是建立CICD流程并不是那么简单。 有人会说，嗯，是的，我要让詹金斯先生，我马上打电话给我，现在我已经准备好CICD。 不，这不仅是一种工具，还是一种实践。 让我们按顺序开始。
第一个。 许多文章写道，所有内容都必须保存在一个存储库中：代码，测试，部署，甚至是数据库架构，以及所有人都通用的IDE设置。 我们走了自己的路。
我们分配了不同的存储库：在存储库中进行部署，在另一个存储库中进行测试。 它工作更快。 它可能不适合您，但对我们来说更方便。 因为在这一点上有一个重要的点-您需要为所有点击流构建简单透明的文件。 当然，您可以将完成的文件下载到某个地方，但是在任何情况下，您都需要自己进行微调，改进。 例如，对我们而言，部署位于其自己的gitflow上，这更像是GitHub流，而服务器开发则位于其自己的gitflow上。
下一段。 您需要配置一个全自动构建。 很明显，在第一阶段，开发人员本人亲自收集了项目，然后他在SCP的帮助下亲自部署了该项目，自己启动了该项目，然后将其发送给任何需要它的人。 此选项没有使用很长时间，出现了bash脚本。 好吧，由于开发人员的环境在不断变化，因此出现了专用的专用构建服务器。 他生活了很长的时间，在此期间，我们设法将服务器增加到500个，在Puppet上配置服务器配置，在Puppet上累积了遗产，拒绝Puppet，切换到Ansible，并且此buildserver继续存在。
他们决定在两次通话后更改所有内容，而没有等到第三次。 故事很清楚：构建服务器是一个单点故障，当然，当我们需要部署某些东西时，数据中心与构建服务器完全融为一体。 第二个调用：我们需要更新Java版本-我们在buildserver上更新了它，在舞台上安装了它，一切都很棒，一切都很棒，而在此基础上，有必要在产品上运行一些小错误修正。 当然，我们忘了回滚，一切都崩溃了。
之后，他们重写了所有内容，以便整个构建完全可以在任何TeamCity代理上进行，并在Ansible上进行了重写，因为它是在Ansible上配置的，为什么不也使用相同的工具进行部署。
遵循以下规则：提交的次数越多越好。 怎么了 因为有第四点：每次提交都被收集。 实际上，甚至比每次提交都多。 我已经说过，我们拥有TeamCity，它允许您从自己喜欢的IDE运行提交（您猜我是什么意思）。 实际上，快速反馈，一切都很好。
损坏的构建将立即修复。 设置自动部署后，您需要在Slack中设置自动通知。 我们都非常了解开发人员仅在编写代码时才知道其代码是如何工作的。 因此：该人员发现-立即修复。
我们测试环境中的重复产品。 很简单，我们选择了Ansible和AWX。 有人可能会问，但是关于Docker，Kubernetes，OpenShift的问题，早已解决了所有现成的问题？ 我忘了说我们拥有Linux和Windows的组件。 而且，例如Windows上的Photon服务器，直到最近我们才能够或多或少地正常包装在10 GB的Docker容器中。 因此，我们有一个Windows应用程序，它不能很好地包装在容器中。 Linux上有一个应用程序（使用Java），该应用程序打包得很好，但是没有理由，无论您在哪里运行它都可以正常工作。 这是Java。
接下来，我们在Ansible和Chef之间进行选择。 它们都可以在Windows上正常工作，但是Ansible对我们来说要容易得多。 当我们已经安装了AWX时-一般情况下，一切都变成了火。 AWX具有秘密，图形，历史记录。 您可以向远非如此的人展示，他将立即看到所有内容，并且所有内容将变得清晰。
而且，您始终需要保持快速构建。 我不知道为什么，但是每当您启动一个新项目时，您就完全忘记了构建服务器，代理，并选择了周围的一些计算机-这就是我们的构建服务器。 重复此错误是不理想的，因为我正在谈论的所有内容（快速反馈和优点）-如果程序集在您自己的笔记本电脑上启动的速度比某种服务器构建场的启动速度快，那么一切都不会那么重要。
7分-我们已经建立了某种CI流程。 太好了 下图不可见，但侧面仍存在Graylog。 谁在Habré上阅读了我们的文章，他们已经
了解了我们如何选择Graylog以及
如何安装 。 无论如何，如果仍然发生任何问题，它有助于偏转。
现在在此基础上已经可以进行部署。
但是我已经在第二段中谈到了部署，因此在此我将不做过多介绍。 我会谈一谈生活：如果您使用Ansible，请确保添加此序列号，该序列号在幻灯片上。 您启动某件事，然后您了解了不止一次，但是我以错误，错误或错误的方式启动它，然后您看到这只是一台服务器。 而且我们很容易丢失一台服务器，而您只需要重新上传一台，就没有人注意到。
另外，他们在Nexus上安装了工件存储库-它是绝对所有人的单一入口，而不仅仅是CI。
它对确保重复性有很大帮助。 好吧，由于nexus可以在不同区域中充当代理服务，因此它们可以加快rpm软件包的部署，安装，docker映像等的部署速度。
当您放置一个新项目时，建议选择易于自动化的组件。 例如，我们没有成功使用Photon服务器。 无论如何，这是其他方面的最佳解决方案。 但是，例如，Cassandra可以非常方便地进行更新和自动化。
这是我们其中一个项目的示例。 客户端进入APP服务器，在那里他在Cassandra数据库中拥有一个配置文件，然后进入主服务器，该服务器在对接会的帮助下为他提供了具有某种空间的游戏服务器。 所有其他服务均以“应用程序-数据库”的形式提供，并以完全相同的方式进行更新。
第二点-您需要提供一个简单的，松耦合的部署架构。 我们成功了。
请参阅，例如更新应用服务器。 我们拥有专用的发现服务，可以重新配置平衡器，因此我们只需转到应用服务器，将其熄灭，平衡器崩溃，我们就可以更新所有内容。 以此类推。
主服务器的更新几乎相同。 客户端ping该区域中的每个主服务器，然后转到ping较好的服务器。 因此，如果我们更新主服务器，则游戏可能会变慢一些，但可以轻松，简单地进行更新。
游戏服务器的更新有所不同，因为仍有游戏在进行。 我们去对接会，请他把某个服务器丢掉，转到游戏服务器，等到游戏完全变为零为止，然后进行更新。 然后我们回到平衡。
这里的关键点是每个组件都具有的端点，并且端点之间可以轻松，轻松地进行通信。 如果您需要一个示例，那么这里有一个Elasticsearch集群。 使用JSON中的常规http请求，您可以轻松地与他进行通信。 并且他立即使用相同的JSON给出了有关群集的各种不同指标和高级信息：绿色，黄色，红色。
完成这12个步骤后，我们增加了环境数量，开始进行更多测试，加快了部署速度，人们开始收到快速反馈。
非常重要的是，我们获得了实验的简单性和速度。 这一点非常重要，因为当进行大量实验时，我们可以轻松过滤掉错误的想法并专注于正确的想法。 并非基于任何主观评估，而是基于客观指标。
实际上，当我们在那里发布部署时，我不再关注。 没有“哦，放开！”的感觉，一切都聚集起来，鸡皮ump。 现在这是例行操作，我定期在聊天室中看到有什么事情发生，好吧。 这真的很酷。 当您这样做时，系统管理员会为之欢呼。
但是世界并没有停滞不前，它有时会反弹。 我们有一些需要改进的地方。 例如，我也想将构建的日志也放入Graylog中。 这将需要进一步完善日志记录，因此没有一个单独的故事，但很明显：这是构建的组装方式，测试方式，部署方式以及在产品上的行为。 以及持续监控-这是一个更复杂的故事。
我们使用Zabbix，而他根本不准备采用这种方法。 第4版将很快发布，我们将找出其中的内容，如果一切不好，我们将提出不同的解决方案。 我将告诉您下一次会议的结果。
听众的提问
当您在生产中倾倒一些垃圾时会发生什么？ 例如，您没有根据性能进行计算，并且集成一切正常，但在生产环境中，外观-您的服务器开始崩溃。 你如何回滚？ 有救我按钮吗？我们试图进行回滚自动化。 然后，您可以讨论有关其工作原理，效果如何的报告。 但首先，我们进行设计，以使这些版本向后兼容并对此进行测试。 当我们做完这件全自动的事情，检查并回滚然后开始使用它时，我们意识到，与只使用相同踏板的旧版本相比，我们付出了更多的努力。 。
关于部署的自动更新：为什么要对当前服务器进行更改，而不是添加新服务器，而只是将其添加到目标组或平衡器？这么快。
例如，如果您需要更新Java版本，则可以在Amazon上更改实例状态，更新Java版本或其他内容，那么在这种情况下如何回滚？ 您要在生产服务器上进行更改吗？是的，每个组件都可以在新版本和旧版本中正常工作。 是的，您可能必须重新加载服务器。
当可能出现大问题时，状态会发生变化...然后爆炸。
在我看来，只是添加一个新服务器并将其放在目标组中的目标组上，这是一项复杂的小任务，而且是一个很好的实践。我们托管在硬件上，而不是云端。 我们可以添加服务器-可以，但是比单击云稍长一点。 因此，我们采用当前的服务器（没有这么大的负载，因此我们无法取出其中的一些机器）-我们取出一些机器，对其进行更新，在那儿输入销售流量，看看它是如何工作的，如果一切正常，那么我们将继续做所有事情其他汽车。
您说如果收集了所有提交，如果一切都不好，则开发人员会立即进行所有操作。 您了解一切都不好吗？ 完成哪些提交？自然，起初是某种手动测试，反馈速度很慢。 然后，通过在Appium上进行某种自动测试，涵盖了所有这些内容，它可以正常工作，并给出有关测试是否失败的反馈。
即 首先，每次提交都会推出，测试人员是否正在监视它？好吧，不是所有人，这是实践。 我们从这12点中进行了一种练习-加速。 实际上，这可能是一项漫长而艰苦的工作，也许是在一年中。 但理想情况下，然后您开始做所有事情。 是的，我们需要某种自动测试，至少需要最少的测试，才能为您工作。
问题是较小的：图片中有一个App服务器，依此类推，那是我感兴趣的吗？ 您说您似乎没有Docker，什么是服务器？ 裸Java还是什么？这是Windows（游戏服务器）上的Photon，而App服务器是Tomcat上的Java应用程序。
即 没有virtualoks，没有容器，什么都没有？好吧，Java可以说是一个容器。
并通过Ansible全面推出吗？是的 即 在某个时刻，我们根本没有投资编排，原因何在？ 如果在任何情况下，都需要以相同的方式分别管理Windows，并且这里绝对所有内容都包含在一个工具中。
以及如何部署数据库？ 依赖组件或服务？服务本身中有一个方案，该方案会在它出现并需要开发时部署，以便什么都不会删除，而只是添加一些东西并且它向后兼容。
您的基地还是铁的，还是亚马逊云中的某个地方？最大的碱是铁，但还有其他碱。 有小的，RDS不再是虚拟的。 我显示的那些小服务：聊天，联赛，与Facebook聊天，氏族，其中之一就是RDS。
主服务器-感觉如何？实际上，这是同一台游戏服务器，只带有主机名，而他是平衡器。 即 客户端对所有主机进行ping操作，然后接收ping次数较少的主机，并且已经使用对接会的主服务器收集了游戏服务器上的房间并发送了玩家。
我正确理解，对于您编写的每个首次展示（如果有任何功能出现），都进行了迁移以更新数据？ 您说过您要拿走旧的工件并填充它-数据将如何处理？ 您是否正在编写迁移以回滚基础？这是非常罕见的回滚操作。 是的，您编写笔迁移及其操作。
服务器更新如何与客户端更新同步？ 即 您需要发布游戏的新版本-首先更新所有服务器，然后更新客户端吗？ 服务器是否同时支持新旧版本？是的，我们正在开发c特征切换和特征调光。 即 这是一个特殊的手柄，可让您稍后打开某些功能的杠杆。 您可以完全从容升级，看到一切适合您，但不包括此功能。 并且，当您已经分散了客户之后，您可以通过精打细算来提高10％的安全性，然后看一切正常，然后充分使用。
您说您已经将项目的各个部分分别存储在不同的存储库中，即 您有某种开发过程吗？ 如果您更改项目本身，那么您的测试将失败，因为您更改了项目。 因此，需要尽快修复单独存在的测试。我告诉您有关鲸鱼“与测试人员的紧密互动”。 仅当存在一些非常密集的通信时，这种具有不同存储库的方案才能很好地工作。 这对我们来说不是问题，每个人都可以轻松地相互交流，有良好的交流。
即 测试人员是否支持您团队中的测试库？ 和自动测试分别位于？是的 您做了一些功能，就可以从测试人员存储库中准确收集所需的那些自动测试，而无需检查其他所有内容。
这样的方法，当一切快速汇总时-您可以负担得起立即进行每次提交的操作。 您遵循这样的策略还是撰写一些发行版本？ 即 每周一次，而不是星期五，也不是周末，您是否有任何发布策略，或者该功能已准备就绪，我可以发布它吗？ 因为如果您从一些小功能中发布一个小版本，那么一切破裂的可能性就较小，如果有什么破裂，那么您肯定知道什么。强迫客户用户每五分钟或每天下载一个新版本并不是一个好主意。 无论如何，您都将依附于客户端。 如果您有一个至少可以每天更新且无需执行任何操作的网络项目，那就太好了。 对于客户而言，故事更加复杂，我们有一些发布策略，我们会坚持下去。
您谈到了将自动化部署到产品服务器，而且（据我所知），还有自动化用于测试的部署-开发环境如何？ 开发人员是否部署了任何形式的自动化？几乎一样。 唯一的不是铁服务器，而是在虚拟机中，但是本质是相同的。 同时，在相同的Ansible上，我们编写了（我们有Ovirt）该虚拟机的创建以及在其上的滚花。
您是否将整个故事与Ansible产品和测试配置一起存储在一个项目中，或者它是单独存在和开发的？我们可以说这些是单独的项目。 当所有东西都装在一个包中时，开发（我们称为devbox）是一个故事，而在产品上则是一个分布式故事。
通过Pixonic DevGAMM进行更多对话