Startup CI system ultimate solution: Gitlab-CI

preface

Here’s an article that’s been delayed for seven months:

Continuous Integration is a complete process of writing lots of unit tests and Integration tests, committing -> testing -> automated deployment with the smallest possible granularity of code changes. In the real world, especially in the fast and rough Chinese Internet community, it is obvious that unit testing alone cannot guarantee code quality, because testing is difficult to cover all business scenarios, especially front-end scenarios, and testing only exists in the most important areas, because writing tests is theoretically more time-consuming and boring than writing business logic.

Therefore, the MAJORITY of CI in China’s Internet sector has only two purposes: ① To ensure the quality of core modules by running tests and eliminate low-level errors; ② APP packaging.

CI Fundamentals

The rationale for continuous integration is actually quite simple:

Git has detected a new code commit (scheduled detection or active trigger), and the task is generated
Agent (the process that does the real work, which can be distributed across multiple machines) picks up the task, pulls the code, and runs a script (it can be used for everything from unit testing to APP packaging)
Show results: success or failure, test coverage, APK IPA download link, etc

Now I will formally introduce Gitlab-CI.

Gitlab-CI

Gitlab profile

Gitlab is the most popular open source Git hosting server today. In fact, Git software itself can provide server services without third-party software, while open source software such as Gitlab Gogs provides advanced functions beyond simple code hosting:

Account system and Web private key management
Friendly Web code viewing, issues, milestone, online code review, etc
Git workflow development: Hook, CI/CD, etc

Gitlab is simple to configure, powerful, and the open source version is extremely rich in features, but it also has a huge disadvantage: high resource consumption. It requires a 2G memory machine, and the instant disk IO in pull or push is quite high, deployment in Ali Cloud will directly lead to virtual machine suspended, only suitable for physical machine deployment with large memory and strong disk. If you can handle a physical server, try installing one.

The advantage of Gitlab – CI

Gitlab-ci is Gitlab’s own continuous integration engine, which eliminates the delay and performance pressure on Git server caused by the third-party CI server that can only periodically check git repository. The reason why our company abandoned OSChina was that the CI server was checked once a minute, and the warehouse was sealed due to too much pressure.

The advantages of GITlab-CI can be summarized as follows:

Trigger cost is low, the system has provided a perfect trigger function
The results are directly displayed in multiple places on the Gitlab page: success/failure, test coverage, and so on
No complex configuration required. (Jenkins’ page logic is backward and extremely complex. TeamCity I thought it was easy to configure until I used Gitlab-ci)

disadvantages

You must use Gitlab.

usage

This article uses the current version 10.1.4 to illustrate the ultra-simple use of Gitlab-CI.

1. Write`.gitlab-ci.yml`Put it in the source code root

Very simply, I post a configuration file for the PHP project I’m using:

before_script:
  - touch ./.env
  - cat /dev/null >| .env
  - |
    echo "ME=Laravel
      APP_ENV=local
      APP_KEY=ooxx
      APP_DEBUG=true
      APP_LOG_LEVEL=debug
    ">>.env

phpunit:
  script:
    - phpunit --coverage-text --colors=neverCopy the code

This is the CI configuration that yamL describes and is easy to read: generate/clear.env, write some information, and then run PHPUnit –coverage-text –colors=never. No, that’s all.

2. Configuration runner

Runner yum install Gitlab-runner, TeamCity agent, TeamCity agent, TeamCity agent, TeamCity agent Then configure it briefly, fill in a few parameters, connect successfully, and you’re done.

Then click Enable in the Settings screen of the matching warehouse.

3. What’s next?

The moment you push the.gitlab-ci.yml file, the task starts, the distribution starts, and the Runner gets to work.

And then, how do I get the result back? The results of the script run will be displayed directly on the Gitlab web page without additional operations. You can even display test coverage directly on a web page:

The setting interface provides the configuration of common languages. The principle is to extract the coverage number from the CLI script running results with the re and display it on the web page. The configuration can be completed according to the prompts.

4. Results presentation

Gitlab home page:

Project CI and CD Details page:

WRITTEN BY

Related logs:

Found an online JPG PNG to ICO website, with a good feeling

Gitlab
Gitlab-CI
Continuous integration
miscellaneous

Startup CI system ultimate solution: Gitlab-CI