我们在golang上提供了一项服务，另外一个主题是kafka，clickhouse，gitlab-ci和一条支付线下降，ssh键烂了，仅此而已，还有假期，城市下大雨，笔记本电脑破损，夜间警报和热销。 并不是所有这些对于本文都是必要的，但是一旦您展示了测试仪的典型日常生活，就可以按照您的意图进行操作了。 唯一困扰我的是p0。 在世界上，没有比在产品上错过它的测试人员更绝望，阴沉而沮丧的人了。 但是我知道我很快就会投入其中。
为什么要这样？
有一个通用的服务捆绑包-服务本身可以完成某些工作-以及将这些结果写入其中的数据库。 有时，这是直接发生的，即“服务基础”。 就我而言，记录是通过中介（即“服务-队列-基本”）进行的。
总的来说，有几个元素，这些元素的边界-一个元素的输出和另一个元素的输入-在这里出现问题。 它们根本不会出现在这里。
一个生动的例子：在服务中，price字段被处理为float32，在数据库中将其配置为十进制（18，5），我们将float32的最大值作为测试用例从服务的输出提供给数据库-哦，数据库没有响应。 或更令人悲哀的例子是-数据库不会崩溃，但是数据库中的数据日志没有错误。 只是数据库不再倒水。 或进行记录，但是数据丢失或失真：该字段以float64形式退出服务，并记录为float32。
或者，在服务生命周期的过程中，他们认为有必要更改此字段或该字段的类型。 该字段早已在产品上实现，但是在此处必须对其进行编辑。 当然，我们仅在一个地方进行了更改。 霍巴，又出了点问题。
挑战赛
我不想跟踪所有这些更改。 我希望它不会倒下。 我希望录制正确。
退出：集成测试！
实施和困难
在哪里休息？
有一个开发环境：非常不稳定，通常被开发人员用作沙箱。 硬后端具有混乱和无政府状态的特征。
有一个测试环境或质量保证站：可以进行更好的调整，即使是开发人员也在观看它，但是除非您踢了它们，否则什么都不会发生。 并且此环境经常更新。 甚至更多的是，那里有东西坏了。
还有一个产品-圣洁的圣物：最好不要在上面开类似的东西。 集成测试表明，可能存在必须在生成产品之前发现错误的错误。
那么当环境不稳定或处于战斗状态时该如何处理呢？ 是的，创建自己的！
与基地怎么办？
数据库可以通过多种方式启动。
如上所述，我们不会连接到该环境或该环境的真正基础。
首先，您可以使用必要的设置来启动
崩溃的 Clickhouse-server，在其上推出必要的sql，并通过clickhouse-client与之通信。 在首次成功建立类似基础的尝试中，ci感到很难过。 测试闪烁，服务器没有熄灭并继续工作。 可以这么说，为什么它甚至开始仍然是一个谜。 （它本身，我与此无关）。 我不建议使用此选项。
开箱即用的便捷选择是使用
docker映像 。
将所需版本下载到您的汽车。 Clickhouse需要config.xml及其设置才能启动。
在这里更多细节
对于重用的单击图像，您需要创建正确的dockerfile。 我们在其中指出要复制config.xl到该文件夹，然后停靠其他必需的配置。 确保复制脚本以部署基础。
由于我们将从外部访问图像，因此我们需要打开与Clickhouse进行通信的端口。 单击可在http的8123和tcp的9000上使用。
我们得到以下dockerfile：
From yandex/clickhouse-server Expose 8123 Expose 9000 Add config.xml /etc/clickhouse-server/config.xml Add my_init_script.sql /docker-entrypoint-initdb.d/
如何在ci中抛出图像？
要以某种方式使用ci中的docker映像，您需要以某种方式对其进行调用。
您可以在存储库中提交并运行映像，并在运行测试的过程中使用必要的参数运行docker run。 仅在这里，单击的docker-image重量不到350mb。 将此类文件保留在git中是不雅的。
另外，如果在不同的项目上需要相同的docker映像（例如，将不同的服务写入同一数据库），则更是如此，因此您不应该这样做。 您可以使用
Docker注册表映像存储
我们相信在我们的项目中它已经存在并被使用。 因此，登录并收集docker映像并将其推送到那里。
docker build -t my_clickhouse_image . docker login my_registry_path.domain.com docker push my_clickhouse_image
下车，我们的图像飞入注册表。 确保在组装过程中指定标签！
基地准备好了。
在此处阅读有关注册表的更多信息
ci怎么办？
如何在一个步骤中同时启动服务和数据库？
这完全取决于我们如何启动和使用该服务。 如果您像使用docker映像一样使用服务，并且实际上整个.gitlab-ci.yml仅适用于它们，则一切都很简单。
有一个奇怪的流浪者-
码头工人 -
码头工人 。 它表示与ci一起使用的主要服务，并允许您充分使用docker而一点也不紧张。
我们抽出最新图像，在阶段中添加所需的测试步骤，并描述我们的操作顺序。
image: docker:stable services: - docker:dind stages: - build … - test-click ... - test - release … test-click: variables: VERY_IMPORTANT_VARIABLE: “its value” before_script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY script: - docker pull My_Service_Image - docker pull My_ClickHouse_Image - docker run -FLAGS My_ClickHouse_Image - docker run My_Service_Image /path/to/tests
官方
docker docker声明不建议使用
dind ，但是如果您确实需要...
在我的项目中，必须通过启动二进制文件来测试服务。 这就是魔术开始的地方。
为此，请将数据库用作服务。 官方的gitlab-ci文档引用了一个带有底脚的容器作为ci中docker容器最常见用例的
示例 。 甚至提供
了 mysql，postress和redis设置的
示例 。 但是我们不是在寻找简单的方法，我们需要一个Clickhouse。
连接底座！ 确保指定别名。 如果未指定，则将为基地分配一个随机名称和一个随机IP。 也就是说，不清楚如何访问它。 别名不会有这样的问题-在测试代码中，调用看起来像是通过
http://my_alias_name:8123 。
对于测试，仍然需要数据库的映像，我们已将其仔细放入注册表中。 要下载映像，您需要进行docker登录和docker pull，只有ci不知道docker是什么-您需要安装它。
gitlab-ci.yml中步骤的结果代码：
Integration tests: Services: - name: my_clickhouse:latest alias: clicktest Stage: tests Variables: Variables_for_my_service: “value” Before_script: - curl -ssl https://get.docker.com/ | sh - docker login -u gitlab-ci-token -p $ci_build_token my_registry_path.domain.com Script: - ./bin/my_service & - go test -v ./tests -tags=integration Dependencies: - build
获利
- 我有一堆工作的服务基础。
- 作为自动测试的一部分，只需通过别名即可轻松访问数据库。
- 作为设置测试的一部分，我重置了数据库的记录和设置，调用了服务，将其写入数据库，转到数据库，我看到数据库还没有崩溃，我看到了到达并验证的内容。 进行更多测试。
- 您不能用笔测试！
结果
似乎在gitlab-ci中有几行设置。 构建docker映像很容易。 在本地运行本地很简单。 我与一天之内发现问题的第一批测试集成在一起。 但是尝试在ci上启动它变成了一周的痛苦和绝望。 而现在，在开发人员必须痛苦和绝望的几周中，他们必须修复在那里编写的所有程序。
我们设法做什么？
- 我们使用Clickhouse设置了一个容器。
- 我们在本地存储中启动了该容器。
- 我们学会了将此图像拖入步骤ci。
- 在跑步者中推出了它。
轻松将数据发送到数据库并从测试中访问它。
自动化是摆脱手工穿孔集成例程的一种非常简单的方法。
需要注意的重要事项：确保基本输入类型与上一个链接的输出类型相对应。 （和说明文件
，如果有的话 ）。