Final Summary, How to Choose a Suitable Workflow Tool in the Cloud Era

Final Summary, How to Choose a Suitable Workflow Tool in the Cloud Era #

Hello, I am Shi Xuefeng. Today we will discuss how to choose a suitable pipeline tool in the cloud era.

In the past few years, I have been focusing on the field of software continuous delivery practices. I have noticed that more and more companies, regardless of their size, are starting to pay attention to building their software continuous delivery capabilities, and almost every company has its own pipeline platform.

In the past, when talking about CI/CD tools, Jenkins was the default option and there weren’t many other good alternatives. However, in the past two years, with the rapid development of cloud container technology, there has been an explosive growth of new tools and solutions in the field of CI/CD pipelines. For example, the not-so-lonely GitLab CI, the lightweight containerized solution Drone. Recently, GitHub Actions has also gained popularity. This shows that as the core tool in the main delivery path, the pipeline is an area that no company wants to miss out on.

For the industry’s development, this is certainly a good thing. Even the veteran tool Jenkins has started to reflect on itself: “In the era of cloud containers, have we been too conservative? Is the old architecture that has been in place for over a decade unable to support the rapid development of the cloud era?” So they took a different approach and incubated the Jenkins X project.

However, for users, it is difficult to choose a tool: “These tools look similar and solve similar problems, so which one should I choose?”

Today, I will summarize the popular CI/CD tools and provide you with some selection recommendations. I have selected 5 tools, divided into 3 groups: Jenkins and Jenkins X from the Jenkins family, GitLab CI and GitHub Actions from the version control system family, and the emerging cloud-native solution Drone, which is rapidly gaining popularity. I will start from 5 aspects to compare and introduce them, including tool usability, pipeline design, plugin ecosystem, extensibility configuration, and applicable scenarios.

Jenkins/Jenkins X #

Regarding Jenkins, I think it doesn’t need much introduction. Over the past 15 years, Jenkins has been silently serving countless software developers. From a set of numbers, we can see its influence: there are over 260,000 clusters, nearly 1,700 plugins, and over 30 million job executions, not to mention the node information from numerous companies and locally run computers. In addition, the biannual Jenkins World conferences often attract thousands of participants, making it a large-scale event in the field of technology conferences.

Of course, the pros and cons of Jenkins are also evident.

  • Pros: High popularity, almost every developer has come into contact with it; mature and rich plugin ecosystem, applicable to any scenario.
  • Cons: Outdated software architecture and UI design style, complex configuration operations; many issues with the security and universality of plugins. Most importantly, in the cloud native domain, it somewhat falls short.

Now let’s talk about Jenkins X. Many people are unclear about the relationship between Jenkins and Jenkins X, just like how it was difficult to explain the relationship between Java and JavaScript at the beginning. In fact, apart from the name containing “Java” and riding on its popularity, JavaScript has no real connection to Java. Similarly, while we cannot say that Jenkins and Jenkins X have no relation at all, they actually target different scenarios and aim to solve different problems. Therefore, it is not accurate to say that Jenkins X is the next generation of Jenkins or that Jenkins will eventually migrate to Jenkins X.

Initially, Jenkins X was indeed a subproject of Jenkins. However, it has now developed its own brand and logo, and along with Jenkins, it is an initial project of the Continuous Delivery Foundation (CDF). The core problem that Jenkins X aims to solve is a native CI/CD solution on Kubernetes . Thus, Jenkins X and Kubernetes are tightly integrated. Its goal is to reduce the development, configuration, and CI/CD usage costs in the cloud native environment through a series of automation tools and best practices, striving to achieve an out-of-the-box experience .

On the other hand, Jenkins is more like a toolbox where you can solve various problems by extending it with plugins, without any definite rules.

Let me give you an example to vividly compare these two projects:

Jenkins is like driving a car. You know the destination, but you decide which route to take, how fast to drive, whether to take breaks, and when to refuel. However, flexibility brings variability, and you never know if the road will be closed the next second or if your car suddenly breaks down.

Jenkins X, on the other hand, is more like a high-speed train. As long as you board the right train, it will safely and quickly take you to your destination, without you needing to worry about how the train is designed, how fast it should go, or even where you can get off—it’s all predetermined.

The Jenkins X project includes a large number of built-in open-source tools and solutions. It can be said to be a utopia and experimental field for open-source tools. Its core purpose is simplicity, speed, and an out-of-the-box experience. For example, the integration with Tekton is seen as an overthrow of Jenkins itself because it completely changes the Jenkins pipeline scheduling mechanism. From the perspective of Jenkins X, Jenkins is just an application within Jenkins X, a black box that is orchestrated through Tekton. In other words, it is not impossible to replace Jenkins with another application.

It is worth noting that Jenkins X has many constraints. For example, you must use the GitOps solution to achieve application promotion and deployment; there is no other choice. If you don’t use Helm to manage your applications and don’t want to use GitOps, then, for now, Jenkins X is not an option for you .

Let’s summarize the Jenkins X project:

  • Tool usability: It adopts an out-of-the-box design, providing many templates to reduce the cost of getting started with CI/CD in new applications. Although the installation is complex, the JX Boot tool has been provided, which helps you set up the environment through an initialization wizard. Moreover, with the introduction of cloud service providers, the environment should be available as a default, just like how you don’t need to worry about building Kubernetes because someone else offers it as a service.
  • Pipeline design: Tekton replaces Jenkins as the default engine for pipelines. As a native solution for Kubernetes, this is also the future trend. In terms of orchestration, it uses YAML and inherits the syntax characteristics of the original Jenkinsfile. It hides and abstracts Tekton resources and is realized through declarative language coding, which can be considered as the current universal solution. However, it does not currently provide a visual orchestration interface.
  • Plugin ecosystem: It inherits Jenkins’ rich plugin ecosystem and vast developer community.
  • Scalable configuration: It adopts a containerized solution, especially for Tekton. Each step is completed within a container, making it highly scalable.
  • Applicable scenarios: I believe that the Jenkins X project is currently in the rapid development stage and is suitable for prototype product verification. For projects that do not have a fixed pattern but want to adopt the Jenkins X design process, you can try using it. However, due to the insufficient integration with cloud service providers, there are still many challenges at the moment. You can keep learning and keeping up with the project. After all, many tools and design ideas in this project are valuable.

GitLab CI/GitHub Actions #

Besides Jenkins, one of the most commonly used tools in China for continuous integration is GitLab CI. There has been a lot of discussion in the community about whether to use GitLab CI or Jenkins. Obviously, no consensus has been reached because “each to their own”. The introduction of GitHub Actions can be seen as GitHub’s attempt to grab a piece of the pipeline orchestration “cake”. In the past, GitHub and Travis CI were a perfect match, just like “open source double jewels”. GitHub has also repeatedly emphasized that they only want to focus on making their code hosting service the best, while leaving other areas to their partners. However, the Package feature and Actions feature released by GitHub demonstrate GitHub’s ambition to build their own ecosystem.

In fact, these two products have many similarities because they both derive from the native pipeline functionality of a mature code hosting platform.

For software development, undoubtedly the most important thing is source code. Previously, a colleague of mine said that if you have control over the source code, you can do whatever you want. For example, you can develop code review tools based on the code, include various static and dynamic code analysis tools, and add package management and dependency management tools. These are essential pre- and post-compile functionalities. Adding built-in continuous integration functionality also helps with machine assistance during code reviews.

When all these functionalities are integrated into a code hosting system, you will find that it is no longer just a simple version control system, but a complete DevOps platform. Their design philosophy is to have one platform solve all DevOps tooling problems. This is also reflected in GitLab’s roadmap, where they have compared mainstream tools and provided a panoramic view of the tools. It can be said that GitLab has achieved the utmost in benchmarking the industry. You can refer to the following panoramic view and their own comparison article: Article.

Image source: https://about.gitlab.com/devops-tools/

Regarding pipelines, both GitLab CI and GitHub Actions have deep integration with the version control systems. Let’s take a overall look from five aspects.

1. Ease of use

  • Easy to get started: Since they are built-in features, GitLab CI/GitHub Actions are very easy to use. You don’t need to build and maintain a separate CI server to achieve this.
  • Native experience: Because they are native features, the experience in terms of pipeline status display and integration with code review workflows is native and the displayed information and richness cannot be compared to standalone CI tools.
  • Integrated collaboration platform: The pain points in DevOps tooling are diverse toolchains, complex integration configurations, and scattered information. The value of an integrated development collaboration platform lies in its ability to solve these problems in a centralized manner. Developers don’t need to jump between various tools and systems, but can solve all problems in one place and see all useful data in one place.
  • Online documentation: GitLab’s documentation and examples are very rich, while GitHub’s documentation is somewhat weaker, but both have sufficient documentation.

2. Pipeline design

  • Pipeline Description: Both GitLab CI and GitHub Actions use YAML files to describe the pipeline process. Although their syntax rules are different, they are similar in essence. However, GitHub’s syntax rules are more in line with the current style of describing Kubernetes resources. For the syntax style of these two products, you can refer to the documentation of GitHub Actions and GitLab CI.

  • Pipeline Editing: Both products support online editing of pipeline files, with GitHub being more user-friendly in this aspect. When you open Actions, the system will recommend some templates for you to directly generate the Actions configuration. If you want to edit the Actions file yourself, the system also provides many example code snippets on the right side, allowing you to easily complete this task by copying and pasting. In addition, the new version of GitHub provides an online visual editor, as GitHub Actions is a newly designed tool that combines various advantages.

3. Plugin Ecosystem

  • GitLab Ecosystem: As an open-source software, one of GitLab’s advantages lies in its openness, and the official team is very responsive to community PRs and features. However, GitLab’s plugin ecosystem is not as well-developed due to its development using the Ruby language and Rails framework. Considering that there are relatively few developers proficient in Ruby language in China, this language has become a bottleneck.

  • GitHub Ecosystem: GitHub has extensive experience in building a marketplace, combined with a large number of open-source contributors. Therefore, in a short period of about a year, they have accumulated over 1700 Actions components that can help you quickly build your pipeline. In terms of extensibility and richness of the ecosystem, GitHub has the upper hand.

  • Cost of Use: It must be emphasized that GitHub is commercial software. Although it adopts a free strategy for open-source projects, if used for enterprise-level projects, the cost is also a factor that must be considered. On the other hand, if you choose the community version of gitLab for self-hosting, there are not as many restrictions, which is also an advantage.

4. Extensibility Configuration

Both platforms support multiple environment types. GitLab has provided support for containers and Kubernetes for a long time, and naturally, GitHub also supports Linux, Windows, and Mac environments. You can also create your own nodes and register them with GitHub. However, it is worth noting that if you are using the non-enterprise version of GitHub, it does not support private deployment. This means that if you want to register internal enterprise resources with GitHub, these resources must be visible to the public.

5. Use Cases

Due to the popularity of self-hosted GitLab services in China, if you do not have high requirements for CI functionality, GitLab CI is sufficient. However, in terms of functionality breadth, due to the lack of a large plugin ecosystem, many functionalities still depend on your own implementation. Therefore, if the software delivery process is very complex and relies on multiple environments, GitLab CI may not be as suitable.

GitHub’s use cases in enterprises are more limited. On the one hand, there is the issue of cost, and on the other hand, SaaS services depend on internal openness. Therefore, if it is an open-source project or a startup project that does not want to maintain a heavy research and development infrastructure, I recommend considering GitHub’s solution.

In the latest 2019 Forrester trend report, both GitLab and Jenkins were listed as cloud-native CI tools and were in a leading position in the industry. You can take a look at the image in the report. Although Jenkins is not explicitly mentioned in the image, CloudBees, the company behind Jenkins, and Google, which currently has deep cooperation in the cloud-native project Jenkins X, are leading players. This indicates that major companies have already started to layout in the cloud-native field.

Forrester’s Trend Report

Drone #

This is also a rising star in the field of CI tools. Many students have mentioned this tool in the comments of our column, which shows that a good tool speaks for itself.

Drone focuses on cloud-native CI and has a very lightweight overall design. Even without much experience, you can quickly get started and build it in one or two days. In my opinion, although Jenkins X also focuses on cloud-native, it introduces a large number of components and process constraints, making it a bit cumbersome overall. In contrast, Drone’s implementation is very elegant, both in terms of pipeline syntax and environment extensibility, which is admirable.

As an open-source software, Drone is implemented using the Go language. In my opinion, Go is made for cloud-native. Whether it is Docker, Kubernetes, or the Jenkins X project I participated in, they are all implemented using Go. Therefore, this project is also a good reference and learning case for internal development teams to quickly improve their DevOps platform building capabilities using Go.

Regarding the Drone platform, I am currently in the learning and exploration stage, and I would like to share my personal opinions on the following aspects.

1. Ease of use

Drone is very easy to set up. You can use self-hosted services or SaaS services. The UI design reflects a delicate concept and looks very refreshing, while also being able to integrate with other tools such as GitHub.

2. Pipeline design

As a cloud-native solution, the pipeline also uses YAML format and has the function of declarative expression and pipeline-as-code. Although it doesn’t have overly complex syntax, Drone’s pipeline syntax style is my personal favorite, and its structure is very clear.

3. Plugin ecosystem

Drone also provides a plugin mechanism, and the official also provides integration support for mainstream version control systems and cloud service providers. Although the number is far from the Jenkins ecosystem, it covers most of the basic tools you can think of. For example, common tools such as Artifactory, SonarQube, Ansible, and even integration with popular communication software in China such as WeChat and DingTalk. Due to its openness, it will provide more plugins in the future.

4. Extensibility configuration

For Drone, the biggest feature is container-first. Although the mentioned tools also support containers, they do not consider containers as the default option. In Drone, containers are standard, which is also a typical characteristic of cloud-native CI tools: everything runs in containers. Because of this, if a non-containerized development and deployment project adopts Drone, it may not be suitable. In addition to the container approach, Drone also supports local execution, which provides possibilities for some special scenarios (such as automation tests with device binding).

5. Use cases

I believe that Drone’s design in cloud-native CI/CD represents the future trend. For products based on container development and delivery, if you are looking for a corresponding cloud-native solution, I recommend using Drone. It is also suitable for small and medium-sized teams and startup companies who want to quickly benefit from CI/CD without investing too much effort. At the same time, as an open-source software developed in Go, you can build your own plugins to meet differentiated needs as your business expands.

Conclusion #

Finally, for your convenience in understanding and comparative learning, I have summarized the characteristics of these five cloud-native pipeline tools in the picture below.

With this, I have finished introducing these mainstream pipeline tools. In conclusion, I would like to add two more points:

  1. Tools are not decisive factors. Do not easily fall into the “toolistic determinism” mindset. Just like true programming experts may not need an IDE, choosing the right tool does not guarantee good results.
  2. Tools follow the principle of “existence is reasonable.” They each have their own strengths in different areas. There is no absolute best tool, only the most suitable one for a given scenario. Also, even with the same tool, it can have different effects in different hands. Choosing the tool you are most familiar with generally won’t go wrong. For example, if you were to ask me which tool to choose, I would definitely recommend Jenkins. But this is not because Jenkins is flawless, but simply because I am used to it.

Thinking Questions #

What practical experience do you have with the application of the Drone tool in a production environment, and what challenges have you encountered?

Please write down your thoughts and answers in the comments section. Let’s discuss together and learn from each other. If you find this article helpful, feel free to share it with your friends.