Learn from 0-1 CI / CD

The needs of modern software development coupled with the deployment of the complexity of the different infrastructures makes creating an application to become a tedious process. When the application appears scale growth, the development team members become more decentralized, fast and continue to produce and distribute software process will become more difficult. To address these issues, the development team began to explore new strategies to make their build, test and release process automation, to help them deploy new production faster. This is the origin continuous delivery and continuous integration development.

This article will explain what CI / CD and how it can help the team to quickly develop and deploy fully tested and reliable software. Before looking at the CI / CD and its advantages, we should practice these techniques and some of the pre-built systems discussed.

Automatic build process

In the software development process, the developer will build process generated code into executable software available. Go to the C language or a compiled language, this phase needs to be generated by running a separate binary source code compiler. For interpreted languages ​​such as Python or PHP, there is no compilation step, but still need to freeze the code within a specific period of time, binding dependencies, packaged for easy distribution. These processes are commonly referred to as "building" or "release" of the workpiece.

While developers can build manually, but doing so have many adverse. First, the introduction of a context switch from the active development to create the build of transition, enabling developers had to stop more productive to focus on the work of the build process. Secondly, every developer in the production of their work, which could lead to the build process inconsistencies.

To address these concerns, many development teams equipped with automatic build the pipeline. These systems monitor the source code repository, and start the build process preconfigured automatically when changes are detected. This configuration without having to involve too much labor in which each and ensures consistent build process.

Many of these steps help users automate the build tool on the market, following is a list of the more popular build tool in the Java ecosystem:

  • Ant: Apache Ant is an open source Java library, founded in 2000. It is the original building tool, Java is still frequently used areas.
  • Maven: Apache Maven is a build automation tool, primarily for projects written in Java. Unlike Apache Ant, Maven follow the convention over configuration principle, need only be configured for aspects of the process of building a reasonable default values ​​deviate.
  • Gradle: 2012 launch of version 1.0, Gradle and Maven Ant attempt to fuse the advantages of modern function by binding to Maven, Ant same time without losing the flexibility provided. Build instructions are written in a language called Groovy's dynamic. Although in this area, this is a relatively new tool, but it has been widely adopted.

version control

Most modern software development requires frequent collaboration in a shared code base. Version control system (VCS) is used to help maintain the project history, parallel processing discrete features, as well as to resolve conflicting changes. VCS allows project easily to adopt changes and roll back if a problem occurs. Developers can handle the project on the local computer, and use the VCS to manage the different development branches.

Record every change in VCS are called to submit. Each submit all changes to the code library cataloging, metadata is also included, for example, about the View Submitted history or merge an updated description.

Figure 1 distributed version control

While version control is a very valuable tool that can help manage many different changes in a single code base. But often their distributed development challenges. Developed after the merger may make it difficult to change the code in a separate branch library in the absence of regularly merged into a shared integrated branch. To avoid this situation, developers are beginning to adopt Continuous Integration practices.

Continuous Integration (CI)

Continuous Integration (CI) is a work of integration will allow developers to share the process branches to enhance the collaborative development. Frequent integration helps solve isolation, reduce the size of each submission, in order to reduce the possibility of merging conflicts.

In order to encourage the practice of CI, ecology has been a powerful tool to build up. These systems integrate VCS library, when a change is detected, automatically run the build script and test suite. Integration testing to ensure that different components can function compatible within a group, so that the team can find a bug compatibility as soon as possible. Therefore, the production of continuous integration build is well-tested, and is completely reliable.

FIG continuous integration process 2

Continuous delivery and continuous deployment (CD)

持续交付和持续部署是在构建持续集成的基础之上的两种策略。持续交付是持续集成的扩展,它将构建从集成测试套件部署到预生产环境。这使得它可以直接在类生产环境中评估每个构建,因此开发人员可以在无需增加任何工作量的情况下,验证bug修复或者测试新特性。一旦部署到staging环境中,就可能需要进行额外的手动和自动测试。

持续部署则更进一步。一旦构建在staging环境中通过了自动测试,持续部署系统将会自动将它部署到生产服务器上。换言之,每个通过测试的构建都是实时的,可供用户及早反馈。这使得团队可以不断发布新特性和修复bug,并以其测试流程提供的保证为后盾。

 图3 CI / CD流程路线图

CI/CD的优势

持续集成、交付和部署对软件开发过程有显著的改进。下文将简单介绍一些CI/CD的主要优势:

快速反馈回路

对于一个快速的开发周期,快速反馈回路显得尤为重要。为了能够实时接收反馈,软件必须迅速触达终端用户。而CI / CD可以通过简化更新生产部署来提供实现此目标的平台。通过要求每个更改都经过严格的测试,CI可以帮助降低每个构建的相关风险并因此使得团队可以便捷地向用户发布有价值的特性。

增加可见度

CI/CD通常是指将IT流程的各个步骤按序列组成一条流水线,且该流水线对整个IT团队(包括开发、测试、运维等团队)均可见。因此,每个团队成员可以跟踪系统中的构建状态并且可以确定任何导致测试失败的构建。团队成员通过深入了解代码库的当前状态,可以更轻松地规划最佳行动方案。这样的可见度为这一问题提供了一个明确的答案——“我提交的更改是否破坏了构建?”

简化故障排除

尽管CI的目标是集成并测试每个发生在代码库中的更改,但是更安全的方式是每次提交都是小型的并尽早将它们合并到共享代码存储库中。如此,当找到bug时,确定和问题相关的更改会更加容易。毕竟,根据问题的严重程度,团队可以选择回滚或编写并提交修复,从而减少生产中解决问题的时间。

软件质量更高

自动化构建和部署流程不仅缩短了开发周期,而且帮助团队开发出品质更好的软件。因为每个更改都会经过充分的测试并且至少会部署在一个预生产环境中,因此团队可以毫无顾虑地将更改部署到生产中。不过,只有当代码库的所有级别,从单元测试到更复杂的系统测试,都有良好的测试覆盖率时,才能实现这一点

集成问题更少

因为自动化测试套件在每次提交时自动生成的构建上运行,所以可以尽早检测并修复集成问题。这使开发人员能够及早了解当前正在进行的工作是否可能影响其代码。它会在一开始就测试由不同贡献者编写的代码是否兼容,而不是在之后可能出现其他问题的时候才开始测试。

有更多的时间专注于开发

CI/CD系统依赖自动化来生产构建并且通过流水线来迁移新的更改。由于不需要手动干预,因此构建和测试不再占用开发团队大块的时间。进而开发人员可以心无旁骛地对代码库进行有效的更改,因为如果构建过程中出现任何问题,自动化系统会通知他们。

持续集成和交付的最佳实践

既然我们已经了解了使用CI/CD的一些优势,那么接下来,我们将讨论一些指导原则来帮助您成功实现这些流程。

对CI / CD流水线负责

开发者直到更改被部署到预生产环境中,才无需对其提交的代码负责。这意味着开发者必须确保他们的代码集成正确并且随时可以部署。如果提交的更改违反了这些要求,则开发人员有责任快速提交修复以避免影响其他人的工作。构建失败应该暂停流水线并阻止不参与修复故障的提交,这使得快速解决构建问题变得至关重要。

确保部署一致

部署过程不需要手动操作,反而流水线需要自动部署流程以确保一致性和可重复性。这减少了将破坏性构建推向生产的可能性,并有助于避免出现一些难以重现的、未经测试的配置。

将代码库提交到版本控制

将每次更改提交到版本控制是十分重要的。这会帮助团队审核所有提交的变更并且让团队可以简单地还原出现问题的提交。同时,也可以保持配置、脚本、数据库和文档的完整性。如果没有版本控制,特别是当多人使用同一个代码库时,会非常容易丢失配置和代码更改或对其处理不当。

提交小的、渐进的更改

开发人员一定要牢记:更改必须是小的。因为等待引入更大批量的更改会延迟测试反馈,会更难以确定问题的根本原因。

良好的测试覆盖率

由于CI / CD的目的是减少手动测试,因此整个代码库应该有一个良好的自动化测试覆盖率,以确保软件按预期运行。此外,还应该定期清理冗余或过时的测试以避免影响流水线。

测试套件中不同类型测试的比例应和“测试金字塔”模型相似。大多数测试应该是单元测试,因为它们拥有基本功能的同时还可以快速执行。此外,还要有较少数量的集成测试,以确保组件可以一起成功运行。最后,应在测试周期结束时包含少量回归、UI、系统和端到端测试,以确保构建满足项目的所有行为要求。可以使用像JaCoCo这样的工具来确定测试套件涵盖了多少代码库

 图4 测试金字塔

结 语

CI/CD的出现大大提高了开发团队的生产效率,缩短了开发周期。其敏捷、稳定、可靠的特性,也越来越被企业所青睐与需要。本文先介绍了系统构建的先决技术与实践,自动化构建、版本控制,并给出了Java环境下一些构建工具,然后分别介绍了持续集成(CI)、持续交付和持续部署(CD)的概念及其优势,并在最后给出了一些最佳实践,如确保部署一致、保证良好的测试覆盖率等

Guess you like

Origin www.cnblogs.com/baizhuang/p/12013418.html
Recommended