Deployment_flow

The basic deployment workflow(usually include at least three environments):

  • Development:
    • Developers work on bugs and features in separate branches. Really minor updates can be committed directly to the stable development branch.
  • Staging:
    • Once features are implemented, they are merged into the staging branch and deployed to the Staging environment for quality assurance and testing.
  • Production:
    • After testing is complete, feature branches are merged into the development branch.
    • On the release date, the development branch is merged into production and then deployed to the Production environment.

目前只有三个环境

  • dev
  • staging
  • master

Project configuration of your jobs with .gitlab-ci.yml (quick start)

  • GitLab offers a continuous integration service. If you add a .gitlab-ci.yml file to the root directory of your repository, and configure your GitLab project to use a Runner, then each commit or push, triggers your CI pipeline.
  • The .gitlab-ci.yml file defines sets of jobs with constraints of how and when they should be run. The jobs are defined as top-level elements with a name (in our case rspec and rubocop) and always have to contain the script keyword. Jobs are used to create jobs, which are then picked by Runners and executed within the environment of the Runner.

details about .gitlab-ci.yml

  • Jobs
    • The YAML file defines a set of jobs with constraints stating when they should be run. You can specify an unlimited number of jobs which are defined as top-level elements with an arbitrary name and always have to contain at least the script clause.
    • Jobs are picked up by Runners and executed within the environment of the Runner. What is important, is that each job is run independently from each other.
  • script: (required, the only required keyword that a job needs) defines a shell script which is executed by Runner
  • image and services
    • allows to specify a custom Docker image and a list of services that can be used for time of the job.
    • stages:
    • stages is used to define stages that can be used by jobs and is defined globally.
    • The specification of stages allows for having flexible multi stage pipelines. The ordering of elements in stages defines the ordering of jobs' execution:
      • Jobs of the same stage are run in parallel.
      • Jobs of the next stage are run after the jobs from the previous stage complete successfully.
    • There are also two edge cases worth mentioning:
      • If no stages are defined in .gitlab-ci.yml, then the build, test and deploy are allowed to be used as job's stage by default.
      • If a job doesn't specify a stage, the job is assigned the test stage.

  • stage:

    • is defined per-job and relies on stages which is defined globally. It allows to group jobs into different stages, and jobs of the same stage are executed in parallel. 
    • e.g.

stages:
  - build
  - test
  - deploy

job 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts

job 3:
  stage: test
  script: make test

job 4:
  stage: deploy
  script: make deploy

  • only and except (simplified)

    • only and except are two parameters that set a job policy to limit when jobs are created:
      • only defines the names of branches and tags for which the job will run.
      • except defines the names of branches and tags for which the job will not run.

  • caches

    • is used to specify a list of files and directories which should be cached between jobs. You can only use paths that are within the project workspace.

    • cache:key

      • The key directive allows you to define the affinity of caching between jobs, allowing to have a single cache for all jobs, cache per-job, cache per-branch or any other way that fits your needs.

      • The cache:key variable can use any of the predefined variables, and the default key, if not set, is set as $CI_JOB_NAME-$CI_COMMIT_REF_NAME which translates as "per-job and per-branch". It is the default across the project, therefore everything is shared between pipelines and jobs running on the same branch by default.

  • asdf

  • asdf

results matching ""

    No results matching ""