Patterns and anti-patterns CI / CD. Part 1

Hello! Friends, on the last day of winter, we will launch a new thread on the “DevOps practices and tools” course. On the eve of the start of the course, we are sharing with you the first part of the article: “Patterns and anti-patterns CI / CD”.



The deployment pipeline task consists of three parts:

• Visibility: All aspects of the delivery system — creation, deployment, testing, and release — are visible to team members and facilitate collaboration.
• Feedback: Team members will learn about problems as soon as they occur, in order to eliminate them as soon as possible.
• Continuous Deployment: With a fully automated process, you can deploy and release any version of software in any environment.

In the above Deployment Pipeline diagram, all patterns have context. Some patterns cover several stages of this pipeline, so I chose the stage at which they are used most often.

1.1 Configuration Management - Patterns and Anti-Patterns

1.1.1 Customizable Third-Party Software

• Pattern: Evaluate and use third-party software that can be easily customized, deployed and automated.
• Anti-pattern: Software that cannot be configured externally. Software without API and command line interface, requiring the command to use the GUI.

1.1.2 Configuration Directory

• Pattern: Support of the catalog of all parameters of each application, ways of changing these parameters and the storage location of each application. Automatic catalog creation as part of the build process.
• Anti-patterns: Configuration parameters are not documented. The catalog of all applications and other assets is local undescribed “folklore”.

1.1.3 Mainline

• Pattern: Minimize merges, control the number of active codeline by working in the mainline.
• Anti-patterns: Several branches per project.

1.1.4 Daily Merdzhi

• Pattern: Changes committed to mainline are applied to all branches at least every day.
• Anti-patterns: Merge all iterations once a week or less than once a day.

1.1.5 Secure Configuration

• Pattern: Storing configuration information in a secure, remotely accessible location, such as a database, directory, or registry.
• Anti-patterns: Open text passwords and / or one computer or share.

1.1.6 Repository

• Pattern: All source files - executable code, configuration, host environment, data - are loaded into the repository with version control.
• Anti-pattern: Some files are checked-in, others, such as environment configurations or data changes, are not. Binary files that can be recreated during the build or deployment process are checked out.

1.1.7 Short-lived Branches

• Pattern: Branches should be short-lived, ideally, several days and no more than one iteration.
• Anti-patterns: Branches living longer iteration. Branches for product functionality, living after release.

1.1.8 The Environment of the Unified Team

• Pattern: Checkout the project repository with version control and run a single command to build and deploy the application to any available environment, including local development.
• Anti-pattern: Require a developer to define and set environment variables. Get the developer to install many build / deployment tools.

1.1.9 One Way to Operation

• Pattern: Configuration management of the whole system - source, configuration, environment, data. Any changes can be traced to a specific revision in the version control system.
• Anti-patterns: Parts of the system have no version. Unable to roll back to the previous system settings software.

1.2 CI Continuous Integration - Patterns and Anti-Patterns

1.2.1 Build Threshold

• Pattern: Build crashes if project rules are violated. For example, violations of architecture, slow tests, violation of standards for writing code.
• Anti-patterns: Manual code review. Detection of problems with code quality in the later stages of the development cycle.

1.2.2 Frequent commits

• Pattern: Each team member checks regularly - at least once a day, but ideally after each task to activate the CI system.
• Anti-patterns: The commit of source files occurs less frequently than once a day, due to the number of changes made by the developer.

1.2.3 Continuous Feedback

• Pattern: Send automatic feedback from the CI system to all members of a cross-functional team.
• Anti-patterns: Notifications are not sent; notifications are ignored; The CI system sends information to everyone that cannot be used.

1.2.4 Continuous Integration

• Pattern: Software build and testing takes place after committing any change to a project versioned repository.
• Anti-patterns: Scheduled assemblies, nightly assemblies, periodic assemblies, assemblies exclusively on the developer's machine, the complete absence of assemblies.

1.2.5 The principle of “Stop Line”

• Pattern: Repair all software delivery bugs as they arise; “Stop line”. No one is checked in a broken assembly, since its repair has the highest priority.
• Anti-pattern: Builds remain broken for a long time, thereby preventing developers from checking for working code.

1.2.6 Independent Build

• Pattern: Written scripts for the assembly, which are separated from the IDE. These scripts are executed by the CI system so that the build is done with every change.
• Anti-patterns: Automatic builds depend on the IDE setting. Unable to start assembly from command line.

1.2.7 Visible Dashboards

• Pattern: It is possible to see all the information about your delivery system. To provide high-quality feedback to an inter-functional team in real time.
• Anti-patterns: Alerts come only to email. Feedback is not published for the whole team.

The end of the first part.

Here is such a material. We will publish the continuation of the translation in the near future, and now we are waiting for your comments and invite you to an open webinar , which will be held this evening.