This post was originally posted by Jenkins Chinese Community

The original article was linked to by Aytunc BEKEN

Maintain multi-branch assembly lines in large enterprises

Without an appropriate solution, it can be difficult to create and maintain a multi-branch pipeline in a large enterprise

Jenkins is one of the best CI/CD tools in the DevOps world. With its unique features, Jenkins can meet almost any of your business requirements. One unique feature is multi-branch pipelining, which allows you to dynamically configure pipelining. However, as your company grows, a single multi-branch line will not be able to meet all your needs, especially if you are involved in large enterprises. You need to consider other issues such as centralized management, governance, stability, constraints and security of the line. So for a large-scale CI/CD environment with a Jenkins pipeline, you need to add more features than you previously thought possible.

Dynamic configuration pipeline

When a developer creates a new branch and pushes it to a remote repository, Jenkins dynamically creates pipelining for the new branch. It is even possible to create a Pull Request pipeline dynamically based on the code repository. This dynamic Feature is useful for teams that use Feature branching or other similar features, and since the topic of this article is not multi-branch pipelining, you can find details and examples in end-to-end multi-branch pipelining project creation.

Pipelining is code

In a multi-branch pipeline, scripts are stored in a project code repository, which is the concept of pipelining as code. Also, it’s useful when you have a small team of developers or a project that doesn’t have a lot of branches. This way, developers can change the pipeline as needed, push the changes to the branch, and see the changes take effect immediately, but for large enterprises with hundreds or thousands of developers with a large number of projects, this solution is not feasible.

A centralized repository

As your team or project grows, it is time to consider an approach that, for example, should be shared across all projects. In the long run, this “centralized repository” becomes critical because as the pipeline grows, new requirements or changes emerge, in which case manually changing each pipeline or script can be a nightmare for an administrator. Therefore, if you are making changes in one place and every pipeline is updated, it is more practical to have this centralized library. This is where the Jenkins shared library concept comes in. For more information, you can visit the site.

Even if you only have a pipeline, you can still use a centralized library.

Governance and stability

If you have developers on your team who have some knowledge of CI/CD, and you are confident that they will not make major changes or write scripting errors that will affect the stability of your environment, it is good to have pipeline scripts in your code. But are you sure?

It is possible for someone to accidentally delete pipeline files or make minor errors that affect CI/CD stability. If you catch them early, it’s easy to fix them. If not, these minor changes or bugs will probably affect CI/CD more than you think, and it will spread to all branches or tags in different projects, which can become very difficult to fix.

Do you need the right line script pushed to the warehouse, all branches and/or code or ask each developer to extract the latest script, this type of problem a centralized repository to solve this kind of more advanced way, in addition to this, your environment will because someone may delete Jenkins file or input some spelling mistakes at risk.

Remote file plug-in

To eliminate the risk of unnecessary changes and reduce the complexity of the libraries used, we need to somehow separate the pipeline script from the project/code repository while still using the multi-branch pipeline functionality. For this, we have a remote file plug-in.

This plugin enables multiple branch line from other warehouse operation/load line script code, rather than put them in the project/code in the warehouse, with this function, you can have a separate code warehouse, you can place all lines in the script, and only provide access to your own. In this way, you will have the same centralized pipelined script repository as a centralized repository. In addition, you can store pipelined scripts in the centralized library itself.

The advantage of this feature is that no one can make changes in the pipeline script except those with access rights. Any changes you make in a centralized pipeline script will affect all multi-branch pipelines that use that script file. This way, you don’t have to wait for all developers to get updates or push scripts to all branches on all repositories.

Another benefit is that if you put a centralized pipelined script into a repository like BitBucket or GitHub, you’ll also have code review capabilities. This way, you can share your code repository with others and still restrict or view changes made by others.

conclusion

Creating a CI/CD pipeline in a large enterprise is not easy, and you need to consider concepts of governance, constraints, stability, and security. In this context, the Remote File Plugin provides a unique capability to centralize, maintain, and share pipelined scripts by leveraging Jenkins’ other capabilities.

For more information about plug-ins, you can visit the plug-ins Wiki page.