Knowledge Transfer

Ethickfox kb page with all notes

Project maintained by ethickfox Hosted on GitHub Pages — Theme by mattgraham

Definitions

The CI/CD Pipeline

109.png

CI/CD Pipeline as Code

A CI/CD pipeline as a script specifies the stages and the order in which the pipeline needs to run successfully. The following script demonstrates basic pipeline stages, such as build, test, and deploy:

pipeline {
   agent {
       docker{
           image 'maven:3-alpine'
           args '-v /root/.m2:/root/.m2'
       }           
   }
   stages {
       stage('Build') {
           steps { 
               sh ‘mvn -B -DskipTests clean package’ 
            } 
       } 
       stage('Test') { 
           steps { 
               sh ‘mvn test’
           } 
            post { 
                always { 
                    junit 'target/surefire-reports/*.xml'
                } 
             }
         } 
         stage('Deploy') { 
            steps { 
                sh './jenkins/scripts/deploy.sh' 
            } 
         } 
    } 
 }

Basic Rules of CI/CD

CI Servers

A CI server―aka a build server―is a tool that enables continuous integration and delivery. Mature versions of a CI server available on the market support different VCSs and allow developers to choose:

Benefits of Using a CI Server

Selecting a CI Server

Концепция, которая реализуется как конвейер, облегчая слияние только что закомиченного кода в основную кодовую базу. Концепция позволяет запускать различные типы тестов на каждом этапе (выполнение интеграционного аспекта) и завершать его запуском с развертыванием закомиченного кода в фактический продукт, который видят конечные пользователи (выполнение доставки)

Виды окружений

A CI/CD pipeline automates the process of software delivery. It builds code, runs tests, and helps you to safely deploy a new version of the software. CI/CD pipeline reduces manual errors, provides feedback to developers, and allows fast product iterations.

CI/CD pipeline introduces automation and continuous monitoring throughout the lifecycle of a software product. It involves from the integration and testing phase to delivery and deployment. These connected practices are referred as CI/CD pipeline.

Continuous integration

An automation process for developers. Successful CI means new code changes to an app are regularly built, tested, and merged to a shared repository. It’s a solution to the problem of having too many branches of an app in development at once that might conflict with each other.In modern application development, the goal is to have multiple developers working simultaneously on different features of the same app. However, if an organization is set up to merge all branching source code together on one day (known as “merge day”), the resulting work can be tedious, manual, and time-intensive. That’s because when a developer working in isolation makes a change to an application, there’s a chance it will conflict with different changes being simultaneously made by other developers. This problem can be further compounded if each developer has customized their own local integrated development environment (IDE), rather than the team agreeing on one cloud-based IDE.Continuous integration (CI) helps developers merge their code changes back to a shared branch, or “trunk,” more frequently—sometimes even daily. Once a developer’s changes to an application are merged, those changes are validated by automatically building the application and running different levels of automated testing, typically unit and integration tests, to ensure the changes haven’t broken the app. This means testing everything from classes and function to the different modules that comprise the entire app. If automated testing discovers a conflict between new and existing code, CI makes it easier to fix those bugs quickly and often.

Continuous delivery

Continuous delivery usually means a developer’s changes to an application are automatically bug tested and uploaded to a repository (like GitHub or a container registry), where they can then be deployed to a live production environment by the operations team. It’s an answer to the problem of poor visibility and communication between dev and business teams. To that end, the purpose of continuous delivery is to ensure that it takes minimal effort to deploy new code. Following the automation of builds and unit and integration testing in CI, continuous delivery automates the release of that validated code to a repository. So, in order to have an effective continuous delivery process, it’s important that CI is already built into your development pipeline. The goal of continuous delivery is to have a codebase that is always ready for deployment to a production environment.

In continuous delivery, every stage—from the merger of code changes to the delivery of production-ready builds—involves test automation and code release automation. At the end of that process, the operations team is able to deploy an app to production quickly and easily.

Continuous deployment

Continuous deployment (the other possible "CD") can refer to automatically releasing a developer’s changes from the repository to production, where it is usable by customers. It addresses the problem of overloading operations teams with manual processes that slow down app delivery. It builds on the benefits of continuous delivery by automating the next stage in the pipeline. The final stage of a mature CI/CD pipeline is continuous deployment. As an extension of continuous delivery, which automates the release of a production-ready build to a code repository, continuous deployment automates releasing an app to production. Because there is no manual gate at the stage of the pipeline before production, continuous deployment relies heavily on well-designed test automation.In practice, continuous deployment means that a developer’s change to a cloud application could go live within minutes of writing it (assuming it passes automated testing). This makes it much easier to continuously receive and incorporate user feedback. Taken together, all of these connected CI/CD practices make deployment of an application less risky, whereby it’s easier to release changes to apps in small pieces, rather than all at once. There’s also a lot of upfront investment, though, since automated tests will need to be written to accommodate a variety of testing and release stages in the CI/CD pipeline.

Could you describe the CI/CD pipelines on the project?

Code Pipelines

Code pipelines are the primary technical artifacts of continuous delivery. Modern-day pipelines transform application and infrastructure source code into versioned packages deployable to any environment. By automating all the mundane tasks to build and deploy systems, teams are free to focus on value-added capabilities.

Pipeline Design Patterns

How would you improve your team's pipeline?

First of all it would be great to add pipelines for our etl services, or at least the deployment part. Because it’s uncomfortable to build it locally, send via ftp and update the current working version manually. For the neli we should add a trigger that will start build and testing process after each push

What is the main purpose of CI/CD?

To automate testing and deployment of your product. To increase development speed. A CI/CD pipeline automates the process of software delivery.

CI/CD pipeline introduces automation and continuous monitoring throughout the lifecycle of a software product.

If you are asked to implement a pipeline yourself what steps would it include?

Example of pipeline