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

This article mainly introduces what Gitlab CI means. It is very detailed and has certain reference value. Friends who are interested must finish reading it.

Gitlab CI is a very powerful continuous integration system with many different functions, and new features are added every time it is released. It also has a wealth of technical documentation, but it lacks a general introduction for users who want to use it on already configured Gitlab. Designers or testers do not need to know how to achieve automatic scaling through Kubernetes, nor the difference between "mirroring" and "services".

At fleetster, we built our own Gitlab instance, and we made heavy use of Gitlab CI. Our designers and testers also use it and like it very much, and its advanced features are great.

However, he still needs to know what a "pipeline" is and how to view branches deployed into an "environment". So, in this article, I will cover as many features as possible, focusing on how end users should use them; in the past few months, I have explained these features to some people on our team, including developers: not everyone knows what Continuous Integration (CI) is, and not everyone has used Gitlab CI.

If you want to understand why continuous integration is so important, I suggest reading this article. As for why you chose Gitlab CI, you can take a look at the instructions on Gitlab.com.

Brief introduction

The act of a developer saving a change to the code is called a commit. He can then push the submission to Gitlab so that other developers can review the code.

Once Gitlab CI is configured, Gitlab can also do some work with this submission. The work of this process is performed by a runner. A runner is basically a server (it can also be something else, such as your PC, but we can simply call it a server). The server executes the instructions in the. gitlab-ci.yml file and returns the execution result to Gitlab itself, which is then displayed on the graphical interface of Gitlab.

After a developer has completed the development of a new feature or a bug fix (these actions usually involve multiple submissions), they can initiate a merge request (merge request), in which other team members can comment on the code and its implementation (comment).

As we will see later, due to the two major features provided by Gitlab CI, environment and artifact, designers and testers can (and really need) to participate in the process, providing feedback and suggestions for improvement.

Piping (pipeline)

Each submission pushed to Gitlab generates a pipeline associated with that submission. If a push contains multiple submissions, the pipeline is associated with the last submission. A pipeline is a collection of job divided into different phases (stage).

All jobs in the same phase are executed concurrently (provided there are enough runners), while the next phase starts only after all jobs in the previous phase have run and returned successfully.

As long as one job fails, the whole pipeline fails. However, as we will see later, there is one exception: if a job is marked as running manually, even if it fails, the entire pipeline will not fail.

The phase is just a logical division of batch jobs, and if the previous phase fails, the latter one is meaningless. For example, we might have a build phase and a deploy phase in which we run all the jobs used to build the application, while in the deployment phase, the built application is deployed. It doesn't make sense to deploy something that fails to build, does it?

There can be no dependencies between jobs at the same stage, but they can depend on the results of the previous phase of the job.

Let's take a look at how Gitlab displays information about phases and phase states.

Gitlab CI basic knowledge Gitlab CI basic knowledge

Pipeline-overview

Pipeline-status

Job (job)

A job is a collection of instructions to be executed by the runner. You can see the output of the job in real time so that the developer can know why the job failed.

The job can be executed automatically, that is, it starts automatically when the push is submitted, or it can be executed manually. Manual work must be triggered manually by someone. Manual work also has its unique role, for example, to automate deployment, but deployment can only be started if someone is manually authorized. This is a way to limit who can run the job so that only trusted people can deploy to continue the previous example.

Homework can also build an artifacts for users to download, such as building an APK for you to download and test on your device; in this way, both designers and testers can download applications and test them without the help of developers.

In addition to generating artifacts, jobs can also deploy the environment, which is usually accessible through URL, allowing users to test the corresponding submission.

The homework state is the same as the phase state: in fact, the phase state is inherited from the job.

Running-job

Product (Artifacts)

As mentioned earlier, the job can generate artifacts for users to download for testing. This artifact can be anything, such as an application on Windows, a picture generated by PC, or even an APK on Android.

So, suppose you are a designer and are assigned a merge request: you need to verify the implementation of the new design!

What should I do?

You need to open the merge request and download the artifact, as shown in the following figure.

Each pipe collects all artifacts from all jobs, and there can be multiple artifacts in one job. When you click the download button, there will be a drop-down box for you to choose which product to download. After checking, you can comment on the merge request.

You can also download artifacts from a pipeline that does not have a merge request.

I focus on merge requests because this is usually where testers, designers, and related people start to work.

But this does not mean that merge requests and pipes are tied together: although they are well integrated, there is no relationship between the two.

Download-artifacts

Environment (environment)

Similarly, jobs can deploy something to an external server so that you can access it through the merge request itself.

As you can see, the environment has a name and a link. Just click the link and you can go to the deployed version of your application (currently, as long as the configuration is correct).

Gitlab also has some other cool environment-related features, such as monitoring, which you can view by clicking on the name of the environment.

The above is all the contents of this article "what does Gitlab CI mean?" Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.