Get best of the week

测试环境门户，或保存我们的开发



几年前，我们感受到了某种超现实的梦想。周围的每个人都去了云进行测试（扩展和折叠测试环境很方便），我们试图找出应该提供的现成工具。为此，我们与客户一起确定了devops流程的工作方式。事实证明，在俄罗斯只有少数公司有能力使用自动化。

我将立即向您解释，在大多数情况下，我们要么与公司中从事最多150-200人开发的人员进行对话，要么与传统上IT困难的行业进行了交谈。大型公司通常都有一个流程和自己的云，他们会来找我们进行备份部署。

生产通常是成熟的。有一个周期，一个发布计划，一个目标，代码与开发人员一起达成目标。

测试和质量检查也经常调试良好。

在它们之间有一个鸿沟。DevOps试图填补这一空白。这个超人应该拿这个版本（最好是用詹金斯或类似的东西组装），制造一辆汽车，在那里放所有东西，检查工作，也许要花一些预测试然后交给质量检查。

问题是什么？


当产品是小型Web应用程序时，就没有问题。开发人员或测试人员直接从备份中获取数据库，连接到最新版本并继续运行。

但是当产品略有增长时，就会出现生产崩溃。

Devops得到了发布，但他接受了它，并没有打算。然后，他开始寻找极限并挑选出开发人员。一个发布可以在晚上收集几个小时，而开发人员通常在白天坐在办公室里。

几乎所有事情都是手工完成的。也就是说，操作员正在坐着并查看装配的进度条。因为任何地方都可能出错。那些精力充沛的人会用自己的脚本绑定所有这些内容，有时结果会非常漂亮和有效。但是我们经常看到交付交付计划是逐步执行的，每个步骤都由一个人负责，并且他很容易用手重复二十次操作，因为否则结果是行不通的。

同时，应该对整个过程负责，这是主要的制止因素。试图找到这样的人常常以失败告终。即，他负责自动化，而对此他很感兴趣。负责各个部分，然后将箭头转移给开发中的人员，当然总是很容易。

虚拟化增加了混乱的更多方面。虚拟环境总是一团糟。负责分组（服务器，机架）的人（无论必​​要与否）定向不良，属于谁。逻辑上，系统管理员不必担心开发人员的状况。但是开发人员应该，但是他的角色通常并不意味着具有这种知识。而且他害怕关闭多余的部分，因为他不知道是否会需要它。

然后有必要为部门之间的相互结算发行内部帐户。有人考虑正常运行时间，有人考虑使用处理器，然后他们平均或按比例分担电费和管理员工作等成本。

出乎意料，但没有成品


似乎整个输送机都应覆盖某种产品。有很多好的解决方案。相同的Ansible可以完美部署，但不知道如何控制虚拟机。管理程序可以。有用于devops脚本编写的所有工具，您可以连接模块...您只需要从此软件链中提取并组装，对不对？

不是这样银行和国有企业都希望在云中进行测试。每个好的保安人员通常都有充分的理由倾向于偏执狂。对于IB银行，每个新安装都是一个非常烦人的因素。我知道有一种情况是操作人员将Jenkins和Terraform拖入基础架构中，在其后部署bash，然后是拥有所有这些功能的DBMS。事实证明，这是一个很好的半自动传送带，可以完成直至完全自动化的部署。仅为了信息安全，这是一场灾难。

他们想要合而为一。并管理虚拟机（以及各种供应商，包括Openstack）。一个应用程序上的客户可以拥有Vmvar，Hyper-in，以及其他一些老旧的东西，无法支持FreeBSD或OS / 2。

我们需要我们的自行车


一般而言，我们编写了平台。引擎盖下-Ansible，开箱即用-与Jenkins集成。您可以为Ansible编写自己的脚本。从子网收集到发布管理，您可以做所有事情。



门户存在于测试环境的范式中。这是它的主要本质。一个测试环境=一个子网。另外，如果确实很糟糕-如果没有API，则可以与RPA集成，并且您需要一个机器人来模拟用户操作并单击界面中的按钮。从应用程序到应用程序都需要考虑计费，正常运行时间和利用率：在销毁请求写入之前，资金将不断减少。

这就是它的样子。使用模板创建环境：



添加虚拟机：



脚本：



事后发现，各方都抱怨“我不想在50个系统上运行”。我们感到非常痛苦。任何经过测试的大客户都想要类似的东西，但是由于某种原因，他们并没有解决问题，也没有与脚本人员组织解决。问题是非常不同的，从无名的虚拟机开始（他们删除了虚拟机，然后有人记得它是必需的），最后是没人愿意对滚动脚本负责。汇总脚本很难编写，法规也很麻烦。周期中的某个地方应该对数据进行匿名处理，看起来像是“在年初时我们建立了一个匿名数据库”，并且软件进行了六次更改，从而更新了数据。

一般而言，如果类似的事情突然对您造成伤害，那就来看看。演示访问可在Technoserv Cloud中获得。

More articles:


All Articles