关于测试,我可以想到两个选择:
- 将测试和应用程序放在一张图中。
- 在图像中仅包含应用程序代码。创建一个特定于测试的容器,该容器在主映像之后构建并向其添加一些层(测试代码,依赖项等)。
使用第一个选项,我可以测试容器并按照测试的要求完全运送它。明显的缺点是不必要的代码(以及潜在的测试数据)将包含在图像中。
使用第二种选项时,出厂的图像与测试的图像不太相同。
两者看起来都是错误的策略。有没有第三种更好的策略?
关于测试,我可以想到两个选择:
使用第一个选项,我可以测试容器并按照测试的要求完全运送它。明显的缺点是不必要的代码(以及潜在的测试数据)将包含在图像中。
使用第二种选项时,出厂的图像与测试的图像不太相同。
两者看起来都是错误的策略。有没有第三种更好的策略?
Answers:
正如您自己所说的,还有第三种方式。我认为您正在混合开发,测试和部署。我建议从整体上看待整个SDLC,以了解您要实现的目标。这是一个很大的话题,但我会尽力总结一下。
简而言之,您需要分开:
每个都需要彼此独立并且适当地:
首先,您有一个由代码和(单独的配置集)组成的应用程序。这需要针对构建功能和有意功能进行测试-这称为连续集成(CI)。在线和本地都有许多此类服务的提供程序,例如,用于云提供程序的CircleCI,它会链接到您的存储库并在您提交时进行构建和测试。如果您的存储库为本地存储,并且无法使用云提供商,则例如Jenkins将是等效的。如果您的应用程序相当标准,则可能存在CI服务可以使用的现有Docker映像。如果不是这样,您将必须创建一个或一个这样的集群,以便将您的应用程序代码和配置部署到其中。正确配置后,您将获得大量有关应用程序代码质量的统计信息。
接下来,一旦您对应用程序的功能和正确性感到满意,就应该为特定版本适当地标记代码库。然后应将此构建部署到测试环境。请注意,该代码将与在CI中测试的代码相同(如果正确执行,则可以证明是相同的),但是配置可能有所不同。同样,某些CI提供程序可以提供此步骤,以便您可以测试打包的应用程序和离散配置的部署。此阶段通常将包括用户功能测试(针对新功能)以及自动化测试(针对已知功能)。如果发行版通过了此阶段,则您有候选发行版用于集成测试。您可以从另一个Docker容器运行自动化测试,一些度量标准表明状态测试工作量与编码工作量是1:1(尽管我不确定自己是什么)。
倒数第二,下一步是在构建(系统)环境时就好像在生产环境一样。如果您在生产中使用Docker,则将在这里考虑安全性加强,网络和服务器优化等。您的Docker映像可能基于您在Development中使用的映像(理想情况下是这样),但可能会在缩放和安全性方面有所变化, 就像我说的。到现在,应用程序的功能测试应该已经完成,您将更加关注安全性和性能。根据功能测试,此处的测试可以从其他Docker映像进行开发,部署和运行。此步骤过去非常昂贵,很少这样做,因此您需要使用专用硬件来复制生产。如今,这完全可行,因为您可以按需站起来拆除几乎任何规模的整个环境。
最后,您应该发布一个发布版本,该发布版本应该仅具有集成测试中的一小部分配置增量(IP地址,数据库URI,密码等)。此时,您的代码库至少已在三个不同的环境中进行了测试点和大多数系统配置至少一次。
我认为您正在混淆各种测试。基本上,您需要问自己:这里要测试的单元是什么?
当您作为开发人员工作时,最常见的情况是为您正在处理的某些代码编写单元/集成测试,其中该代码段是被测单元。您可以在本地和/或CI中运行这些测试。
构建新的Docker映像后,它将成为可以测试的新单元。您想为这张图片测试什么样的东西?它提供了什么API?您如何测试?
如果是Web应用程序,则可以基于图像启动容器,并执行一些HTTP请求,并检查响应是否符合您的期望。我认为您遇到的问题是,您非常习惯将测试框架与应用程序代码耦合在一起。在开发过程中很好,但是现在您想要测试docker映像,因此您需要一种新型的测试框架,该框架可以做到这一点,并且与应用程序代码无关。
因此,我认为您正在寻找的第三个选择是:
因此,CI / CD步骤为:
设置开发环境->在代码上运行测试->构建最终映像->在映像上运行测试->部署映像。