What are the CI/CD tools you are familiar with?
https://www.zhihu.com/question/296006908/answer/562263043
Recommend some top open source CI/CD tools, here is just a brief description of these CI/CD tools-they all have more cool features and differences, you can continue to study them. They are all open source, free to use, and you can deploy them to see which suits your needs best.
GitLab CI
- Project page:
https://about.gitlab.com/product/continuous-integration/ - Source code:
https://gitlab.com/gitlab-org/gitlab-ce/ - Follow the MIT license agreement
GitLab is a novice player in the CI/CD field, but it has taken the lead in the Forrester Wave continuous integration tools. This is a huge achievement in such a field with many competitors and high levels. What makes GitLab CI so great?
- It uses YAML files to describe the entire pipeline.
- It also has a feature called Auto DevOps, which enables simpler projects to automatically build pipelines with several built-in tests.
- Use the Herokuish build package 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 the production environment at the beginning of the development process.
- Provide native integration to the Kubernetes cluster, and use one of a variety of deployment methods (such as percentage-based deployment and blue-green deployment) to automatically deploy applications to the Kubernetes cluster.
In addition to the CI function, GitLab also provides many supplementary functions, such as automatically deploying Prometheus and your application together for operational monitoring; using GitLab issues (Issues), epics (Epics) and milestones (Milestones) for project portfolio and Project management; the pipeline has built-in security checks to provide aggregated results across multiple projects; the ability to edit code in GitLab using WebIDE, it can even provide a preview or execute part of the pipeline for faster feedback.
GoCD
- Project page:
https://www.gocd.org/ - Source code:
https://github.com/gocd/gocd - Follow the Apache 2.0 license agreement
GoCD comes from the hands of the masters of Thoughtworks, which proves its ability and efficiency. For me, the main difference between GoCD and other tools is its value stream map (VSM) feature . In fact, the pipeline can be connected with the pipeline to provide "material" for the next pipeline. This makes the teams with different responsibilities in the deployment process more independent. This may be a useful feature when introducing this type of system in an old organization that wants to maintain team isolation. However, let everyone use the same tools, and it will be easier to find the bottleneck in the VSM in the future. That's it. Reorganize the team or work to improve efficiency.
It is very valuable to equip each product of the company with a VSM; GoCD allows it to be described in the form of JSON or YAML in the version control system, and displays all the data about the waiting time in a visual way, which makes this tool It is more valuable for people who want to better understand their organization. Starting from the installation of GoCD, only manual approval gates are required to complete the process mapping. Then let each team use manual approval so you can start collecting data where there may be bottlenecks.
Travis CI
- Project page:
https://docs.travis-ci.com/ - Source code:
https://github.com/travis-ci/travis-ci - Follow the MIT license agreement
Travis CI is my first time using a software-as-a-service (SaaS) CI system, and it is great. The pipeline is stored in the source code in the form of YAML and can be seamlessly integrated with tools such as GitHub. I don't remember the last time the pipeline failed due to Travis CI or integration-Travis CI has a very long uptime. Not only can it be used as SaaS, but it also has a hosted version. I haven't run this version yet because it has many components and it seems a bit difficult to install.
I think it will be much easier to deploy it to Kubernetes using Helm Charts provided by Travis CI. These Charts did not deploy all the content, but I believe that it can deploy more content in the future. If you don't want to deal with these troubles yourself, there is also an enterprise version.
However, if you are developing open source code, you can use the SaaS version of Travis CI for free. This is a great service provided by a great team! This greatly reduces overhead and allows you to use a fairly common platform to develop open source code without having to run anything.
Jenkins
- Project page:
https://jenkins.io/ - Source code:
https://github.com/jenkinsci/jenkins - Follow the MIT license agreement
Jenkins is one of the earliest and prestigious tools in the CI/CD field, and is the de facto standard. For most non-developers, Jenkins may be a big burden, and it has been a burden on its administrators for a long time. However, these are the things they want to solve.
Jenkins configuration as code (JCasC) should help solve complex configuration problems that have plagued administrators for many years. Similar to other CI/CD systems, it allows the zero-touch configuration of the Jenkins master node through YAML files. Jenkins Evergreen's goal is to simplify this process by providing predefined Jenkins configurations based on different use cases. These distributions should be easier to maintain and upgrade than the standard Jenkins distribution.
Jenkins 2 introduces native pipeline features with two pipeline types. When you are doing simple things, neither of these two methods are as easy to operate as YAML, but they are very suitable for more complex tasks.
Jenkins X is a complete transformation of Jenkins, and is likely to be 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 the best way locally in Kubernetes. This is an exciting time for Jenkins, and I look forward to its innovation and continued leadership in this field.
Concourse CI
- Project page:
https://concourse-ci.org/ - Source code:
https://github.com/concourse/concourse - Follow the Apache 2.0 license agreement
The first time I heard that Concourse was introduced by a colleague from Pivotal Labs, it was an early Beta version-there were not many similar tools at the time. The system is composed of microservices, and each job runs in a container. One of the most useful features that it exclusively provides is the ability to run a job from the local system (which can be modified locally). This means you can develop locally (assuming you are connected to the Concourse server) and run the build as in the actual build pipeline. In addition, you can rerun the failed build from the local system and inject specific changes to test the fix.
Concourse also has a simple extension system based on the basic concept of resources. Basically, every new feature you want to provide to the pipeline can be implemented in the Docker image and included in the configuration as a new resource type. This allows all functions to be encapsulated in a single immutable artifact that can be upgraded and modified independently, and breaking changes does not necessarily break all builds at the same time.
Spinnaker
- Project page:
https://www.spinnaker.io/ - Source code:
https://github.com/spinnaker/spinnaker - Follow the Apache 2.0 license agreement
Spinnaker comes from Netflix, and it focuses more on continuous deployment rather than continuous integration. It can be integrated with other tools, including Travis and Jenkins, to initiate testing and deployment pipelines. It also integrates monitoring tools such as Prometheus and Datadog, and deployment decisions can be made based on the indicators provided by these systems. For example, canary deployment uses the concept of judgment and collected indicators to determine whether the latest canary deployment has caused a decline in related indicators, whether it should be rolled back, or whether the deployment can continue.
Some additional and unique features related to deployment cover an area that we often overlook when discussing continuous deployment. It may even seem to be the opposite, but it is critical to success: Spinnaker can make continuous deployment difficult. So continue. It can prevent a certain stage from running at a specific time, thereby preventing deployment from occurring at critical moments in the application life cycle. It can also force manual approval to ensure that it is released when the business can get the most from the change. In fact, the whole point of continuous integration and continuous deployment is to be ready to deploy changes as soon as the business needs them.
Screwdriver
- Project page:
http://screwdriver.cd/ - Source code:
https://github.com/screwdriver-cd/screwdriver - Follow the BSD license agreement
Screwdriver is a very simple project. It uses a microservice approach and relies on tools such as Nomad, Kubernetes, and Docker as the execution engine. For deployment to AWS and Kubernetes, it provides a good deployment tutorial, but once the Helm Charts in progress are completed, it can be improved.
Screwdriver also uses YAML for its pipeline description and contains many reasonable default settings, so there are relatively few sample configurations for each pipeline. This configuration describes a high-level workflow, and there can be complex dependencies between jobs. For example, one job can be guaranteed to run after or before another job. Jobs can be run in parallel and then connected. You can also use logical operators to run jobs, for example, if any dependencies of the job succeed, or only all dependencies succeed. More conveniently, you can specify a specific job triggered from a pull request. In addition, when this happens, the dependent job will not run, which allows you to easily isolate the pipeline to determine when the artifact should be put into production and when it still needs to be reviewed.