Table of contents
One: What does "continuous" mean?
2.1 CI: Continuous Integration
2.3 Continuous Delivery (Continuous Delivery)
Three: Advantages of Continuous Integration (CI) / Continuous Deployment (CD)
Four: What are the CI/CD tools we are familiar with?
4.3 Functional comparison of Jenkins vs GitLab CI/CD
4.4 Advantages and disadvantages of Jenkins vs GitLab CI/CD
4.4.2 Disadvantages of Jenkins
4.4.3 Advantages of GitLab CI/CD
4.4.4 Disadvantages of GitLab CI/CD
4.5 How to choose Jenkins vs GitLab CI/CD?
Foreword:
Assembly lines in factories create consumer goods from raw materials in a rapid, automated, and repeatable manner. Likewise, software delivery pipelines generate releases from source code in a fast, automated, and repeatable manner. The overall design of how this is done is called "Continuous Delivery" (CD) . The process of starting an assembly line is called "Continuous Integration" (CI) . The process of ensuring quality is called "continuous testing" and the process of delivering the final product to users is called "continuous deployment". Some experts make it all run easily, smoothly, and efficiently. These people are called DevOps practitioners.
One: What does "continuous" mean?
"Continuous" is used to describe following many of the different process practices I've mentioned here . This doesn't mean "always running", but " ready to run " . In the field of software development, it also includes several core concepts/best practices. these are:
Release frequently: The goal behind the continuous practice is to be able to deliver high-quality software frequently. The delivery frequency here is variable and can be defined by the development team or the company. For some products, quarterly, monthly, weekly, or daily deliveries may be frequent enough. For others, multiple deliveries a day may be required. The so-called persistence also has an "occasional, on-demand" aspect. The end goal is the same: to deliver high-quality software updates to end users in a repeatable, reliable process. Often this can be done with little to no user interaction or knowledge (think device updates).
Automated processes: The key to achieving this frequency is the use of automated processes to handle every aspect of software production. This includes building, testing, analysis, version control, and in some cases deployment.
Repeatable: If we use an automated process that always behaves the same way given the same input, then the process should be repeatable. That is, if we take a certain historical version of the code as input, we should get the same deliverable as output. This also assumes that we have the same version of the external dependencies (ie we don't create other deliverables that the code uses for that version). Ideally, this also means that the processes in the pipeline can be versioned and rebuilt (see the DevOps discussion later).
Rapid iteration: "Fast" is a relative term here, but regardless of the frequency of software updates/releases, the expected ongoing process is to transform source code into deliverables in an efficient manner. Automation takes care of most of the work, but the automation process can still be slow. For example, for a product that needs to release candidate updates multiple times a day, a round of integrated testing that takes more than half a day may be too slow.
Two: CI/CD overview
CI/CD is an approach to frequently deliver applications to customers by introducing automation in the application development phase.
The core concepts of CI/CD are continuous integration, continuous delivery and continuous deployment. It refers to automatically executing a series of processes from development to deployment during the development process, minimizing manual intervention.
Specifically, CI/CD enables continuous automation and continuous monitoring throughout the application lifecycle (from integration and testing phases, to delivery and deployment) . These associated transactions are collectively referred to as the "CI/CD pipeline" and are supported collaboratively by the development and operations teams.
CI refers to continuous integration, and CD refers to continuous delivery and continuous deployment. Taken together, these processes usually include:
2.1 CI: Continuous Integration
Continuous integration means that multiple developers can frequently merge code lines together in the process of developing different functional codes without affecting each other's work.
The purpose of continuous integration is to allow products to iterate quickly while maintaining high quality. Its core measure is that the code must pass automated tests before it is integrated into the backbone. As long as a single test case fails, it cannot be integrated.
Continuous integration does not eliminate bugs, but makes them very easy to find and correct.
Note: In simple terms, continuous integration is to frequently integrate code into the trunk. Deliver the part of the software developed by the individual to the overall part of the software, and integrate it frequently so that errors can be found faster.
Benefits :
- Quickly find errors. Every time a bit of update is completed, it will be integrated into the backbone. Errors can be found quickly and it is easier to locate errors
- Prevent the branch from greatly deviating from the trunk. If the trunk is not integrated frequently and the trunk is constantly updated, it will make it more difficult to integrate in the future, or even difficult to integrate
- Release updates faster Continuous integration can help teams release and update programs faster and more aggressively. A large amount of repetitive work can be automatically completed when publishing, saving manpower
2.2CD: Continuous deployment
CD (CD-continuous deployment, continuous deployment) is based on a certain tool or platform to automate the construction, testing and deployment of code to the online environment to deliver high-quality products. Continuous deployment represents a development team to some extent The update iteration rate of .
Continuous deployment is the next step in continuous delivery, which means that after the code passes the review, it is automatically deployed to the production environment.
The goal of continuous deployment is that at any moment the code is deployable and ready for production.
Note: The premise of continuous deployment is to automate the steps of testing, building, and deploying.
2.3 Continuous Delivery (Continuous Delivery)
Continuous delivery is to deliver products to the online environment on the basis of continuous deployment, so continuous delivery is a delivery of product value and a profitable realization of product value.
Continuous delivery refers to the frequent delivery of new versions of software to quality teams or users for review. If the review passes, the code goes into production.
On the basis of continuous integration, continuous delivery deploys the integrated code into "production-like environments" that are closer to the real operating environment. Continuous delivery prioritizes software deployment throughout the product lifecycle, built on a high level of automated continuous integration.
Note: continuous delivery can be seen as the next step of continuous integration
Three: Advantages of Continuous Integration (CI) / Continuous Deployment (CD)
1) Continuous integration/continuous delivery is the foundation of the modern software development cycle
2) In traditional software development methods, each feature update or bug fix is released at intervals, which significantly increases the chances of coupling changes at deployment time
3) Continuous Integration/Continuous Delivery can solve all these problems and make the whole process more manageable and efficient.
4) In modern software development practices, Continuous Integration (CI)/Continuous Delivery (CD) is the basis for building, testing and deploying applications into production.
5) Continuous Delivery (CD) helps reduce risk and achieve production consistency by automating multiple code changes from different project developers.
6) On the other hand, Continuous Delivery enables developers to seamlessly deliver integration code into production, providing a fast and efficient automated process to easily release new features and updates to customers
7) Advantages of continuous integration/continuous delivery pipeline:
- Manage minor code changes
- Fault isolation prevents errors in the short term
- Reduced mean time to resolution (MTTR)
- Improve test reliability
- speed up the release
- reduce backlog
- Drive customer realization
- Enhance team transparency and accountability
- cut costs
- Easy to maintain and update
Four: What are the CI/CD tools we are familiar with?
4.1GitLab CI
GitLab is a relatively new player in the CI/CD space, but it has taken the lead in the Forrester Wave for continuous integration tools. It's a huge achievement in a field where there are so many competitors at such a high level. What makes GitLab CI so awesome?
- It uses a YAML file to describe the entire pipeline.
- It also has a function called Auto DevOps, which enables simpler projects to automatically build a pipeline with several built-in tests.
- Use the Herokuish buildpack to determine the language and how to build the application. Some languages can also manage databases, which is an important feature for building new applications and deploying them to production at the very beginning of the development process.
- Provides native integration into Kubernetes clusters and automatically deploys applications into Kubernetes clusters using one of several deployment methods such as percentage-based deployment and blue-green deployment.
In addition to the CI function, GitLab also provides many supplementary functions, such as automatically deploying Prometheus with your application to achieve operation monitoring; using GitLab issues (Issues), epics (Epics) and milestones (Milestones) for project portfolio and Project management; pipelines have built-in safety checks, providing aggregated results across multiple projects; the ability to edit code in GitLab using WebIDE, which can even provide previews or execute parts of pipelines for faster feedback.
4.2Jenkins
Jenkins is one of the oldest and well-established tools in the CI/CD space and is the de facto standard. Jenkins can be quite a burden for most non-developers, and has long been a burden for its administrators as well. However, these are matters that they want to address.
Jenkins Configuration as Code (JCasC) should help solve complex configuration problems that have plagued administrators for years. Like other CI/CD systems, it allows zero-touch configuration of Jenkins master nodes via YAML files. Jenkins Evergreen aims to simplify this process by providing predefined Jenkins configurations based on different use cases. These distributions should be easier to maintain and upgrade than standard Jenkins distributions.
Jenkins 2 introduces native pipeline functionality with two pipeline types. Neither approach is as easy to manipulate as YAML when you're doing something simple, but they're great for more complex tasks.
Jenkins X is a complete transformation of Jenkins, quite possibly the implementation of cloud-native Jenkins (or at least what most users will see when using cloud-native Jenkins). It will use JCasC and Evergreen and use them in an optimal way natively in Kubernetes. These are exciting times for Jenkins, and I look forward to its innovation and continued leadership in this space.
4.3 Functional comparison of Jenkins vs GitLab CI/CD
Both Jenkins and GitLab CI/CD have areas of expertise and technical followers. However, when discussing the Jenkins vs GitLab CI/CD debate, many features are discussed.
4.4 Advantages and disadvantages of Jenkins vs GitLab CI/CD
4.4.1 Advantages of Jenkins
- Extensive plugin library
- Self-hosting, i.e. full control over the workspace
- Easy to debug and run due to absolute control over the workspace
- Easy to build nodes
- Easy to deploy code
- very good credential management
- Very flexible and versatile
- support different languages
- very intuitive
4.4.2 Disadvantages of Jenkins
- Complicated plugin integration
- For smaller projects, the overhead is relatively high, because you need to build it yourself
- Lack of analysis of the entire pipeline trace
4.4.3 Advantages of GitLab CI/CD
- Better Docker integration
- It is relatively simple to run the program to expand or shrink
- Jobs within a stage are executed in parallel
- Opportunities for DAG pipelines
- Very easy to scale up and down due to running programs concurrently
- Merge Request Integration
- easy to add assignments
- Easy to handle conflict issues
- Good Security and Privacy Policy
4.4.4 Disadvantages of GitLab CI/CD
- Builds need to be defined for each job and upload/download
- It is not possible to test the merge status before the actual merge has occurred
- Subdivision phases are not yet supported
4.5 How to choose Jenkins vs GitLab CI/CD?
Both Jenkins and GitLab CI/CD have their own advantages and disadvantages, and your final choice between these two tools depends on project requirements and specifications. Each of these CI/CD tools has its own strengths and weaknesses, and all were released to fulfill the exact same need: to automate the process of CI/CD (Continuous Integration and Delivery). Jenkins is used for continuous integration, while GitLab CI/CD is used for code collaboration and version control. When choosing the best CI/CD tool for DevOps testing, you should look at the price list and in-house proficiency in addition to standout features.