[toc]git
持续交付(CD, Continuous delivery)就是说每次提交代码时当即构建,并能够将构建部署到生产环境中,本文将分享一些持续交付相关的方法和经验。github
自动化对于完善的CD管道来讲必不可少,咱们理应尽量的用自动化取代手动工做以得到最大利益。数据库
过去,咱们的开发团队可能在将代码发布到生产环境以前通常会作测试,其中一些多是手动的,一些则是自动的。但在持续交付的状况下,每次提交都要进行代码测试,所以最好的办法就是“自动化一切可自动化的东西”,而且不该仅限于开发团队。安全
软件中全部重要部分的自动化都是必要的——微信
根据咱们的产品不一样,可能还会有不少其余可自动化的部分,例如基于云计算的产品,能够自动配置基础架构。架构
CD流程的第二个重要基础是“常常提交、尽快提交”的能力,在交付软件时,快速的反馈周期能够带来极大的不一样。app
然而不幸的是,大爆炸开发方法和部署(Big bang development approach and deployments)还是业界的常态。用这种方式,每隔几个月、一次性发布大量代码到生产环境中很常见。运维
而在代码中引入大量更改并将其部署到生产系统中可能会产生意外后果。很难确切地知道出了什么问题,并且诊断起来很困难。以这种方式更新的大型系统很难恢复到工做状态,由于您没法轻松回滚。微服务
持续交付要求您常常将更改与主分支集成。每次更改代码时,请将更改推送到版本控制。性能
若是咱们没有成天commit,通常没法确切知道咱们的commit如何适应系统的其余部分,或者它是否已经破坏了任何东西。若是咱们使用的是版本控制系统,开发人员能够切换到过去任何给定时间点的代码。
频繁提交的另外一个积极结果是咱们能够更快地得到有关项目状态的反馈,咱们很快就会发现某个解决方案走错了方向,而若是出现问题,咱们只须要调试一些潜在的部分。另外,不要忘了有意义的提交备注很重要!
当开发人员长时间彼此孤立地工做时,实现CD几乎是不可能完成的任务。在大公司中,持续数月的开发周期并不罕见。当开发工做以这种方式发生时,在开发阶段结束时须要进行大量测试,这也就意味着在至关长的一段时间里,咱们没法了解应用是否正常工做。
避免这种不肯定性须要开发人员常常commit他们的工做,尽快让更改对其余人可用。在大型团队中,这一点很重要,这使得合并冲突和由大型提交引发的其余问题变得不那么频繁且更易于解决。
先进的软件开发公司通常都至少遵循了Agile/Scrum方法的一部分。例如,Scrum的一个仪式是团队天天进行讨论:昨天作了什么、今天要作什么以及有什么困难,这么作的目的是让整个团队了解正在进行的工做。
提升开发团队生产环境知识的一种简单方法是让运维工程师参加,让开发团队可以更好地了解运维所作的工做。
从长远来看,咱们须要DevOps,避免开发和运维成为两个孤岛。
CD的最后边界是部署到生产环境中。对于生成代码库的每次提交,不须要进行生产部署,但每一个构建都须要生产就绪。
大多数开发团队对实际生产环境、硬件和软件的规范、配置、安全规则等了解很少,甚至根本没法访问生产环境。
改善这种状况须要采起的第一步,是创建一个尽量接近真实生产环境的临时环境。
有效实施CD的常见障碍是克服一体化架构代码库的“迟缓”,缓慢的构建、脆弱的代码库、复杂的代码和架构是一些常见的问题。
常见的方法是从新构建整个系统,但通常方法会涉及到大量的时间、资源和资金,以及技术挑战。
对于那些不专一于软件开发的公司来讲,要得到管理层的批准要困可贵多,由于这须要额外的预算和精力分配到可能只是微不足道的边际收益的事情上。
对于其余更注重软件的公司而言,从长远来看,从新构建整个解决方案多是最好的方法。
咱们建议的入门方法是将代码库拆分为多个存储库,每一个存储库都集中在整个产品的较小子集上。这些较小的存储库中的每个都应该是自包含的,它们应该有本身的构建脚本、测试等。
如此一来,CD流程能够更快实现,而无需对系统进行完全“检修”。从长远来看,应使用微服务架构方法将这些单独的存储库进一步细分为更小的部分。
Rainbond(云帮)是"以应用为中心”的开源PaaS, 深度整合基于Kubernetes的容器管理、ServiceMesh微服务架构最佳实践、多类型CI/CD应用构建与交付、多数据中心资源管理等技术, 为用户提供云原生应用全生命周期解决方案,构建应用与基础设施、应用与应用、基础设施与基础设施之间互联互通的生态体系, 知足支撑业务高速发展所需的敏捷开发、高效运维和精益管理需求。