General introduction to Gitlab CI

General introduction to Gitlab CI

At fleetster, we built our own Gitlab instance, and we used Gitlab CI in large quantities. Our designers and testers are also using it, and they also like it. Its advanced features are amazing.

Gitlab CI is a very powerful continuous integration system with many different features, and new features will be added each time it is released. Its technical documentation is also rich, but for users who want to use it on the configured Gitlab, it lacks a general introduction. Designers or testers do not need to know how to achieve automatic scaling through Kubernetes, nor do they need to know the differences between "Images" and "services.

However, he still needs to know what a "Pipeline" is and how to view the branches deployed in an "environment. Therefore, in this article, I will try to cover as many features as possible, focusing on how end users should use them. In the past few months, I explained these features to some of our teams, including developers: not everyone knows what Continuous Integration (CI) is, and not everyone uses Gitlab CI.

If you want to know why continuous integration is so important, I suggest you read this article. As for how to choose Gitlab CI, you can go to the Gitlab.com instructions.

 

Introduction

The developer's action to save and change the code is called a commit. Then he can push the submission to Gitlab, so that other developers can review the code.

After Gitlab CI is configured, Gitlab can also handle this submission. This process is executed by a runner. The so-called runner is basically a server (or something else, such as your PC, but we can simply call it a server ). This server executes.gitlab-ci.ymlThe command in the file, and return the execution result to Gitlab itself, which is then displayed on the Gitlab graphical interface.

After developers develop a new function or fix a bug (these actions usually include multiple commits), they can initiate a merge request, other team members can comment on the Code and its implementation in this merge request.

As we will see later, due to the two major features provided by Gitlab CI, environment and product artifact allow designers and testers to participate in this process (and are really needed, provide feedback and improvement suggestions.

 

Pipeline

Each commit pushed to Gitlab generates a pipeline associated with the commit. If one push contains multiple commits, the pipeline is associated with the last commit. A pipeline is a set of job jobs divided into different stages.

All jobs in the same stage are executed concurrently (with enough runners available), and the next stage starts only after all the jobs in the previous stage are run and return success.

Once a job fails, the entire pipeline fails. However, as we will see later, there is an exception: if a job is marked as a manual operation, the entire pipeline will not fail even if it fails.

The stage is only a logical division of Batch jobs. If the execution of the previous stage fails, the execution of the next stage is meaningless. For example, we may have a build phase and a deploy phase. In the build phase, we run all the jobs used to build the application. In the deployment phase, we will deploy the built application. However, it makes no sense to deploy a building failure, isn't it?

Jobs in the same stage cannot be dependent on each other, but they can depend on the running results of jobs in the previous stage.

Let's take a look at how Gitlab displays information about stages and stages.

Pipeline-overview

Pipeline-status

 

Job

A job is a set of commands to be executed by the runner. You can view the output result of the job in real time, so that the developer can know why the job fails.

The job can be executed automatically, that is, the job can be executed automatically or manually after the push is submitted. A manual task must be manually triggered by someone. Manual jobs also have their own unique functions, such as automated deployment, but deployment can only begin with manual authorization. This is a way to limit who can run jobs, so that only trusted people can deploy the jobs to continue with the previous instances.

Jobs can also construct artifacts for users to download. For example, you can build an APK for you to download and test it on your device. In this way, designers and testers can download and test applications without the help of developers.

In addition to generating products, jobs can also be deployed.EnvironmentIn general, this environment can be accessed through URL, allowing users to test the corresponding submission.

The job status is the same as the stage Status: in fact, the stage status is inherited from the job.

Running-job

 

Product Artifacts

As described above, a job can generate products for users to download for testing. This product can be anything, such as applications on Windows, images generated by PCs, and even APK on Android.

Assume that you are a designer and assigned a merge request: You need to verify the implementation of the new design!

What should I do?

Open the merge request and download the product, as shown in.

Each pipeline collects all products from all jobs, and one job can have multiple products. When you click the Download button, a drop-down box will show you which product you want to download. After checking, you can comment on this merge request.

You can also download the product from the pipeline without merging requests ;-)

I pay attention to merging requests because this is usually the place where testers, designers, and related personnel start to work.

However, this does not mean that merge requests and pipelines are tied together: although they are well combined, there is no relationship between them.

Download-artifacts

 

Environment

Similarly, a job can deploy something on an external server so that you can access the content by merging the request itself.

As you can see, the environment has a name and a link. You only need to click the link to go to the deployment version of your application (currently, only if the configuration is correct ).

Gitlab also has some other cool environment-related features, such as monitoring. You can click the environment name to view them.

Environment

 

Summary

This is a brief introduction to some features in Gitlab CI: It is very powerful and can be used properly to allow the entire team to use a tool from planning to deployment. Since many new features are available every month, please stay tuned to the Gitlab blog.

If you want to know how to set it or want to know its advanced functions, see its documentation.

In fleetster, we not only use it to run tests, but also use it to automatically generate software of various versions and release them to the test environment. We have also automated other tasks (building an application and releasing it To Play Store ).

Do you want to work with me and many other amazing people in a young and dynamic office? Look at these positions in fleetster!

Praise the Gitlab Team (and other people who offer help in their free time). They are doing a great job!

If you have any questions or feedback on this article, please send me an email: riccardo@rpadovani.com or push me to :-) you can suggest me add content, or rewrite the content in a clearer way (English is not my mother tongue ).

So, goodbye,

R.

P.S: If you think this article is useful and want us to write other articles, would you like to buy me a beer to bring me to the peak of Ballmer?

Via: https://rpadovani.com/introduction-gitlab-ci

Author: Riccardo Translator: lujun9972 Proofreader: wxy

This article was originally compiled by LCTT and launched with the honor of Linux in China