What is Continuous integration/Continuous deployment (CI/CD)?

To put it bluntly, this means handing over the work of testing, packaging, and publishing code to some tool to automate. This increases efficiency and reduces errors, and developers only need to worry about developing and committing code to Git.

How to do?

  • Method 1: Use Web hooks, which work by adding a request URL and a Secret to the Setting-Integrations Settings of the GitLab project, as shown below

    When the hook condition is triggered, (usuallygit pushAfter),gitlabThe activesecretTo precede a request in the request headerurlThe back-end service accepts the request and validates itsecretAnd then you can do whatever you want. This approach does not require continuous integration tools, but requires you to write a back-end service. As the following method 2 is mainly used today, the specific method of method 1 will not be expanded, you can refer to itGitlab Webhooks Deployment automation combat

  • Method 2: Use tools such as Gitlab-CI. The principle of this method is to register Gitlab-Runner for the project on its own server installation, and the registration will have a token. After running Gitlab-Runner on the server, Runner will poll and send HTTP request with token to Gitlab. If Gitlab has a task (usually git push), the task information will be returned to Runner. The runner then calls the Executor chosen at registration (I’m using shell) to execute the.gitlab-ci.yml configuration file at the root of the project, and reports the results back to Gitlab. For more details on how it works, what should we talk about when we talk about GitLab CI? For those who are a little confused about gitlab-CI and Gitlab-runner, please read this article. Here are my personal steps:

    1. Develop a front-end project (which I named Ci-Test) in a development environment (such as my own Windows) and push it to the GitLab remote repository. Here is a vUE project generated with VUe-CLI 3.0. I personally like to add the following custom configurations

      //vue.config.js
module.exports = {
    outputDir: 'app-page'// Define the name of the packaged directory. Note that baseUrl is also omitted from the.gitnore file:'/'// Package with relative path}Copy the code

    2. Configure nginx on the server and configure the default access directory, for example my own configuration is /app folder. Search for specific methods.

    3. Install Node and git, and clone the gitlab repository in the /app/ci-test directory on the server

    4. Install Gitlab-Runner on the server. For details, please refer to the official documentation

    5. To register a Runner on the server, refer to the official documentation for details. Note that the URL (usually https://gitlab.com) and token should be entered here. Look at setting-CD/ Cd-runners -Specific Runners under gITLab (figure below).

      And fill it outtagsAlso useful, in the back.gitlab-ci.ymlThe inside of thetagThe choices have to be heretagsThe subterm inside, and then finallyexecutorI’m going to fill it out hereshell

    6. Modify gitlab-Runner permissions after registration

      sudo chown -R gitlab-runner:gitlab-runner /home/gitlab-runner
sudo chmod -R 777 /home/gitlab-runner
Copy the code

    7. Start the Gitlab-Runner service

      gitlab-runner run
Copy the code

      If successful, there will be a green dot, as shown below

    8. Configure the. Gitlab-ci. yml file in the root directory of the vue project. Please refer to the documentation for specific configuration options. My configuration is as follows:

          This file is executed when Runner detects a task on Gitlab through polling
    # I am not very familiar with the syntax and detailed configuration of YML, so I have to look for some suggestions on optimization

    stages:
        - update
        - test
        - build

    Update the code and install dependencies
    update:     
        stage: update
        script:
            - cd /app/ci-test       # Go to the project directory first
            - git pull
            - sudo npm install
        tags:                       # Tags must belong to the tags that you filled in when registering
            - update
    
    # Execute unit tests
    test:
        stage: test
        script:
            - cd /app/ci-test
            - npm run test:unit
        tags:
            - unitTest
    
    # packaged
    build:
        stage: build
        script:
            - cd /app/ci-test
            - npm run build
        tags: 
            - build

Copy the code

    9. < span style = “box-sizing: border-box; line-height: 22px; word-break: inherit! Important; word-break: inherit! Important

      statusIf that column is greenpassedThen you are done, and you only need to submit the code each time, and no longer need to test the deployment manually. At this point, go to the browser to open the corresponding address, you can see the deployment is successful. Mine looks like this:

      If it’s redfailedAn error occurs when executing a command. In this case, an email is sent telling the cause of the failure.

reference

  • Build continuous integration environment based on Gitlab CI
  • Gitlab Webhooks Deployment automation combat
  • Gitlab-ci implements front-end automation deployment (Steps comprehensive)
  • GitLab – CI and GitLab – Runner
  • What should we talk about when it comes to GitLab CI