Shulou(Shulou.com)06/03 Report--

This article will explain in detail how to use GitLabCI to achieve multi-module project CI/CD. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

The advantages of Monorepo in developing multi-service applications. And how to easily build, test, and deploy such applications using GitLab CI/CD and Docker.

Applications based on modern Web usually contain a variety of services. For example, back-end API and front-end clients. In large projects where scale expansion becomes a problem, services can also be split into multiple micro-services. How to organize the source code in such a project? One solution is monorepo, where all source code in the project is managed in the same repository. Another way is to create a repository management for each microservice. The monorepo approach allows easy access to the entire code base, which brings many advantages, such as ease of code reuse and simplified dependency management. However, the process of semantic versioning and deployment of each service will be more complex.

I'll use a sample project to explain the concept of monorepo and its deployment. The project is a Web application consisting of only two services: the back end and the front end. For example, the back end could be a Node.js application that runs on a server and provides REST or GraphQL API. The front end can be a single-page application written in a JavaScript framework (such as React or Vue.js) that is provided to the client by a simple Web server.

All source code is managed in one monorepo. Our simple project has the following file structure:

Monorepo/ backend/ src/ Dockerfile frontend/ src/ Dockerfile .git / .gitignore. Gitlab-ci.yaml docker-compose.yaml

We use the Docker container during local development and in the production version on the server. Therefore, each service has a Dockerfile that describes its Docker image. The file docker-compose.yaml is used to configure and start the container in the local development environment. You can use similar files to run the application on the server, or you can use Docker orchestration tools such as Kubernetes.

CI/CD pipeline

Our goal is to automatically build, test, and deploy the application to the server each time a new version (that is, "code commit to GitLab") is released. This includes building and testing services, bundling each service in a Docker image, and storing those images in a (private) GitLab Docker Registry. Finally, the server is automatically notified of the new version and triggers the extraction of the new image from the registry. All of this can be done through GitLab CI / CD. This is a very powerful tool. Basically, the GitLab CI / CD pipeline consists of several phases such as build,test and deploy. The pipe is configured with a file called .gitlab-ci.yaml, which is stored in the root directory of our repository. In the case of monorepo, we must make sure that the correct phase of the GitLab CI / CD pipeline is triggered. Moreover, we usually only want to build, test, and deploy those services that have changed in the application, rather than merging all the services together, because this can be very time-consuming.

In the .gitlab-ci.yaml file, we define the job for each service and each phase. To ensure that the service's job is executed only after the service source code has been changed, we can use the only/changes clause in conjunction with the regular expression of the folder path. For example, a build job for a back-end service can be defined as follows:

Backend_build: stage: build only: changes:-"backend/**/*"...

Script only needs four lines of code in the job section to build a Docker image of the backend service and push it to GitLab Docker Registry.

Backend_build:... Script:-docker login-u $DOCKER_USER-p $ACCESS_TOKEN $CI_REGISTRY-cd backend-docker build-f Dockerfile-- tag latest. -docker push latest...

In the first line, we log in to GitLab Docker Registry with a user name and access token that have previously defined $ACCESS_TOKEN in the variable name $DOCKER_USER and in the settings of the GitLab project. Then, we go to the backend/ folder, run the Docker build command, and finally push the image to the registry.

Our service tests can be performed in another job, such as backend_test. The commands and scripts required depend largely on the test infrastructure of our project, but basically, the scripts we call are the same as those used in the local development environment. More complex tests, such as integration or end-to-end testing, can also be done with GitLab CI / CD. Once built and stored in the registry, the Docker image of the service can be easily placed in the CI/CD pipeline and used as a service container in testing.

Once built and tested, our Docker image is ready to deploy. We define a deployment job for each service of the application, where we log on to the server and trigger the extraction of the new image from the GitLab Docker image repository.

On "how to use GitLabCI to achieve multi-module project CI/CD" this article is shared here, I hope the above content can be of some help to you, so that you can learn more knowledge, if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.