Questions tagged «continuous-deployment»

什么是工件存储库？如果这只是存储文件的地方，我是否只能使用源代码控制系统？

29 terminology  continuous-delivery  continuous-deployment  artifacts 

以下是连续积分当前内容的引文： ...经常将开发人员的工作代码副本合并到共享代码库中的过程，以防止或最小化集成问题。 好我知道了 但是接着还有连续交付和 连续部署，这就是我不断迷失的地方： 假设通过您沿生产线的某个地方最终将到达目标环境，那么持续集成与持续交付和/或持续部署之间的关系如何。integrationdeliveringdeployed 持续交付和持续部署之间有什么区别？ 过去，在将DevOps称为DevOps之前，我们使用了术语，可能有助于理解这些新的DevOps术语，例如： 推动到（或降级从）一些预先PROD目标，任选地与一些类型的再生过程（编译，结合等）的组合中可执行状的东西封装所有相关组件在一起。那应该类似于/接近连续集成吗？ 使用FTP之类的工具（如果标准副本无法弥合差距）将其分发到某些目标环境，但尚未在目标中激活它。那应该类似于/接近连续交付吗？ 在某些目标环境中安装（或激活），并结合诸如绑定，停止/启动操作等内容。这应该类似于/接近于连续部署吗？

20 continuous-integration  terminology  continuous-delivery  continuous-deployment 

与尝试对数据库（尤其是RDBMS）使用相同的方法相比，连续交付或持续部署基础结构和代码相对简单。部署完成后，代码和基础架构将不会更改或发展。但是，如果数据库不是架构固有的可变组件，则将向数据库中添加新数据，从而构成数据。 我知道有一些做法，例如仅添加数据库对象（即表和列），从不修改或删除它们-这种纯粹的累加方式来处理数据库架构，具有确保架构向后兼容的优势，但代价是顺序复杂一些模式。 同样，还有诸如Flyway和Ready Roll之类的产品，它们可以帮助编写要在模式版本之间编写的迁移。 当前存在哪些其他实践和工具可以将数据库架构连续部署到关注数据完整性的生产环境中？

17 continuous-delivery  continuous-deployment  databases 

我已经注意到，在集成测试过程中，我实际上使用的是Restful API（或一般的HTTP接口）的重复使用案例，我在这里和那里使用bash + cURL进行检查。 它开始看起来非常凌乱，并且变得难以维护。为什么要乱成一团？ 典型的用例是： 检查URL是否返回http响应代码，例如200 在这种情况下，检查内容类型是否与您需要的某些MIME相匹配 检查返回的内容是否匹配某种模式，或通过抽象验证过程 到目前为止，我发现并在不重新发明轮子的情况下认为是可行的选择是： 可以使用PyCurl-希望它可以完全实现所有cURL选项esp。代理以及其他我可能需要的开关 使用Python的内置单元testng 然后，例如，我可以检查每个服务一项单元测试： import unittest, pycurl class TestService (unittest.TestCase): def test_1(self): self.assertEqual(pycurl.returncode("some_url"), 200) def test_2(self): self.assertTrue(pycurl.response("some_url").matches ("xxx") ) def test_3(self): self.assertTrue (pycurl.ContentType("some_url").equal("xxx")) if __name__ == '__main__': unittest.main() 这是否有意义？或者是否有更高级的工具（但不太复杂，无法使用和集成）？

14 testing  continuous-deployment  python  curl 

关于“ 持续集成如何与持续交付/部署有何关系？ ”这一问题的公认答案也解释了持续交付和持续部署之间的微小差异。它似乎与以下问题的答案有关：“您想如何将其部署到生产中，而这些（专有）选项是您可以从中选择的： 自动）。 手册。 我无法想象在DevOps墙的另一侧会有一个可怜的“操作员”，他将不得不做与“手动”所指的内容相对应的事情……我的问题： （在我的问题中）我对“分发”与“安装”的引用是否接近这种“手动”东西的可能实现？这是我相关问题的相关报价： 使用FTP之类的工具（如果标准副本无法弥合差距）将其分发到某些目标环境，但尚未在目标中激活它。那应该类似于/接近连续交付吗？ 在某些目标环境中安装（或激活），并结合诸如绑定，停止/启动操作等内容。这应该类似于/接近于连续部署吗？ 它还有其他可能的实现方式吗？

13 continuous-delivery  continuous-deployment 

我很好奇其他人如何在严格的变更管理环境（例如，变更咨询委员会（CAB）批准流程）中构建其DevOps做法。 我知道自动化可以通过保证更严格，可证明和可重复的过程来改善您的审核过程。但是，在这种情况下，感觉连续部署几乎是不可能的。由于可能需要一周或更长时间才能批准更改，因此您将失去快速且经常部署的能力。除了提交变更请求和等待批准之外，您还需要采取什么步骤来在这些流程中工作？

12 continuous-deployment 

TL; DR：您是否知道iOS的托管CI / CD提供商，它们的数据中心/构建盒位于亚洲或至少在欧洲？（如果他们提供构建和部署，则奖励点，但是构建是MVP。） 幕后故事： 我们正在针对iOS和Android大规模运行CI / CD：我们同时运行10多个版本，以测试/验证我们的Merge-Request分支，并将主干版本部署到测试人员和涉众。我们正在使用我们非常满意的SaaS /云提供商...除了它们的位置。 我们在亚洲，正如我们的消息来源一样。客户处于一个受到严格监管的行业中，并且为使源保持在本地状态而进行了艰苦的努力，因为他们认为他们的监管者尚无法处理云中的源。请接受这个前提。我了解为什么他们需要放手。但是现在……假设他们做不到。 这意味着：来源在亚洲，但是构建它的CI / CD提供者似乎都在美国（Circle，Buddybuild等）。跨太平洋的带宽很低，尤其是在亚洲工作日。在大多数工作日中，每个克隆在每次构建之前花费的时间会超过60分钟。 对于CI / CD而言，在docker容器上进行Android构建非常容易。但是iOS是问题所在。您要么需要自己去教别人管理OSX并保持大量的构建盒正常运转，要么需要让专家为您解决该问题。 笔记： 我不是在寻求建议，SE社区！这是一个实际的技术问题：在特定的地理位置是否提供满足某些技术要求的某些服务？ 我们知道MacStadium可以在爱尔兰提供裸MacOS VM。但这意味着您必须管理自己的整个CI流程，以及我们宁愿避免的许多低级系统管理任务。当然，这也意味着将构建与部署分开。但是延迟似乎是可以接受的。 我们知道其他人拥有更接近我们的云CI / CD平台...但是没有iOS / MacOS支持。 我们知道浅层克隆需要较少的带宽，这可以缓解问题，但是它们还具有其他复杂性，这意味着我们当前的提供商尚不支持它。而且它们在任何情况下都不能完全解决问题。 我们已经尝试过使用非本地GitHub镜像，该镜像解决了一些问题，但没有解决监管问题。它也不适用于许多Webhook，特别是对于我们的CI管道中的新代码至关重要的Merge-Request Webhook。我们可以创建一个代理来监视webhooks，然后将API命令强制中继给其他服务提供者...但这确实是一个难题，而且我们还创建了许多新代码来维护。

9 continuous-integration  continuous-deployment  ios  software-as-a-service