什么构成了良好的CI构建过程?
我们使用CI,但是如果您依赖于应该部署的多个服务而其他应用程序也可能依赖于这些目标,那么即使是实际的CI目标也要部署到生产中.
一个好的CI构建过程是否足够好,当它从那里自动化QA和手动?
这得看情况" :)
我们使用CI系统:
构建和单元测试
部署到单个框,运行集成测试和代码分析
部署到实验室环境
在类似prod的系统中运行验收测试
drop build传递给prod部署的代码drop
这是一个绿地项目,包括部署到20多台服务器的大约十二个服务和数据库,这些服务和数据库也依赖于其他六个"外部"服务.
使用CI工具将产品部署到生产环境中作为现实目标?再次......"这取决于"
你为什么想做这个?
如果您拥有该流程,则可以更快,更频繁地滚动更改(并回滚)
减少人为错误的机会
您可以在进入生产之前在测试环境中测试相同的部署策略并更早地发现问题
在您回答这个问题之前,您必须解决一些技术问题:
您的系统的正常运行时间要求是什么?您是否允许停机或是否需要全天候运行?
您是否有适当的变更控制流程需要人工干预/批准?
您的部署是否足够强大,以便任何组件在部署失败时回滚到已知良好状态?
是您的系统设计用于处理不同版本的服务或客户端,以防一个或多个组件部署失败(并且您有上述回滚到上次已知的好处)?
该流程是否具有智能来处理部分无法处理其依赖关系/客户端的混合版本的部分部署?
你是如何处理数据库部署/升级的?
你有适当的监控,所以你知道什么时候出错吗?
以下是有关自动化和构建所需工具的最新相关链接.
当它归结为它时,你的系统越复杂,自动化一切就越困难,但这并不意味着它不是一个有价值的目标,它只需要更多的努力和意志力来完成它 - 从知道的一切你将面临的困难,你必须考虑的问题(失败将会发生),建设基础设施的政治挑战(与更多的产品功能相比).
现在这是一个大秘密......技术挑战具有挑战性但并非不可能...... 政治挑战可能是不可逾越的.无论是开发时间还是购买第三方解决方案,关于此的一切都需要花钱.那么,你真的可以建立1K,1万美元,10万美元或100万美元的解决方案吗?
无论您采用何种解决方案,都要确保自动化首先是健壮的,完全是第二个...即确保您拥有尽可能强大的解决方案,以便部署到测试环境而不是部署到生产的脆弱解决方案.