To make a long story short, this paper presents a panorama of our project team gitLab Flow && Devops

  • Git Flow defines a branching model for project release, providing a robust framework for managing large projects with scheduled release cycles.
  • DevOps emphasizes that teams accomplish software lifecycle management through automated tool collaboration and efficient communication, resulting in faster and more frequent delivery of more stable software. Development focuses on code, operations focuses on deployment, and efficiency and quality are improved.

I. Team background

  • A small team of 10 people is also practicing agile development.
  • Each sprint cycle typically contains 2-3 features;
  • Both front and rear end development are adopted, and k8S is used for production deployment;
  • Intergate Test– > Alpha –> PROD for each Sprint launch cycle.

Modern Devops technology enables environment-dependent packaging, versioning, and agile deployment based on container technology and automated scripting.

Ii. Operation by our company

To strike a balance between iteration convenience and deployment rigor, the project team (actually I… The following Gitlab flow & DevOps process was designed.

A complete feature iteration live cycle:

Stage 1: Development stage

  • Developers cut out feature branches from Develop. The project manager sorts out feature branches that need to be launched in this sprint and merges them into Develop after self-testing.
  • At this point, the “Develop branch” image is printed and automatically deployed to the integration test environment, which is theoretically code restless;
  • Developers should focus on the integrated test environment, and QA staff can participate as appropriate.

Stage ② : test stage

  • After the integration test environment validates, the release-1.0.0 pre-release branch can be cut from Develop, and the “release-1.0.0 pre-release branch “image will be printed and automatically deployed to the alpha environment.
  • QA spends a lot of time testing on this environment, finding problems, and developers responding quickly;
  • The BugFix branch will be cut from the relex-1.0.0 branch and immediately merged back to the relex-1.0.0 branch after repair. It will also be automatically deployed to alpha for quick QA verification.
  • .
  • In this phase we kept approaching a stable release-1.0.0 branch.

Stage 3: Deployment phase

  • Git tags: v1.0.0 from the stable relex-1.0.0 branch, where the ImageTag:v1.0.0 image, need to manually deploy to prod;
  • QA online test, can not fix the problem, quickly use the previous ImageTag rollback;
  • If a bug that cannot be rolled back is found after launch, hotfix is needed. Hoxfix branch is still cut out from relex-1.0.0 and merged back to relex-1.0.0 after repair. Alpha environment test is passed. Git tags: v1.0.0-hotfix1 redeployed to Prod
  • .
  • Confirm that the release is successful, merge the release-1.0.0 branch back to develop and Master

If the feature branch merges back into the Develop branch, the develop branch will be contaminated and the master branch will be retained as a backstop.

The next step is to start a new sprint cycle, with git Release branch /tag names following the iteration.

Iii.Gitlab Flow is combined with containers

The whole process implements the core usage of git Flow pre-release branch release and hotfix, and also has some improvement in deployment mode.

  • Integration test and alpha environments use git branch names (develop or release-1.0.0) as mirror tags for rapid iteration and automatic deployment.

For continuous automatic deployment of branches, I tried to use the branch name as the image name. In fact, git branches are not like git tags, and the code of git branches can change, so I used a “flag” operation:

Find the snapshot (commit_id) of this branch and type ‘branchName: {commit_id}’ as a mirror tag. The suffix of this mirror tag locates this code snapshot!

  • Prod requires that the git Tag be printed from the Release branch with the git Tag name as a mirror Tag, which is a general practice. Manually click deploy, place deployment at will!

Homework cheat sheet

Docker-compose was used for integration test. Alpha and PROD are deployed using K8S;

According to the twelve elements App methodology, one code, multiple deployments!

Alpha and prod are different machine environments. Write appropriate scripts for deployment in different environments. After logging in to the machine using SSH, execute the deployed scripts.

Gitlab – ci files

stages: - build - build_image - deploy build: stage: build script: - pwd - "for d in $(ls app/src); do echo $d; pro=$(pwd)/app/src/$d/$d.csproj; dotnet build $pro; done" tags: - my-tag build_image:EAPWebsite: stage: build_image script: - dotnet publish app/src/EAP.Web/EAP.Web.csproj -c release -o container/app/publish/ - if [ $CI_COMMIT_REF_NAME ! = "$CI_COMMIT_TAG" ]; then CI_COMMIT_REF_NAME=$CI_COMMIT_BRANCH.$CI_COMMIT_SHORT_SHA; fi; Git tag is not a normal git tag. Tag - docker build -t $DOCKER_REGISTRY_HOST/eap/website:$CI_COMMIT_REF_NAME container/ app-docker login $DOCKER_REGISTRY_HOST -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD - docker push $DOCKER_REGISTRY_HOST/eap/website:$CI_COMMIT_REF_NAME tags: - my-tag only: - tags - develop-master - /^release-.*$/ I # - if [ $CI_COMMIT_REF_NAME != "$CI_COMMIT_TAG" ]; then CI_COMMIT_REF_NAME=$CI_COMMIT_BRANCH.$CI_COMMIT_SHORT_SHA; fi; Git tag is not a normal git tag. Tag -echo $CI_COMMIT_REF_NAME -ssh -t [email protected] "CD /home/eap/website && export TAG=$CI_COMMIT_REF_NAME && docker-compose pull website && docker-compose -f docker-compose.yml up -d" dependencies: -build_image :EAPWebsite tags: -my-tag only: - develop # develop branch, automatically deploy to integration test environment - if [ $CI_COMMIT_REF_NAME != "$CI_COMMIT_TAG" ]; then CI_COMMIT_REF_NAME=$CI_COMMIT_BRANCH.$CI_COMMIT_SHORT_SHA; fi; Git tag is not a normal git tag. Tag -echo $CI_COMMIT_REF_NAME - SSH -t [email protected] "export Tag =$CI_Deploy_ImageTag && ./eapwebsite_cd.sh" dependencies: - build_image:EAPWebsite tags: - my-tag only: - /^release-.*$/ I # release-1.0.0 - if [ $CI_COMMIT_REF_NAME != "$CI_COMMIT_TAG" ]; then CI_COMMIT_REF_NAME=$CI_COMMIT_BRANCH.$CI_COMMIT_SHORT_SHA; fi; Git tag is not a normal git tag. Tag -echo $CI_COMMIT_REF_NAME -ssh -t [email protected] "export Tag =$CI_COMMIT_REF_NAME && /eapwebsite_cd.sh" dependencies: -build_image :EAPWebsite tags: -my-tag only: -tags when: manual # prodCopy the code
  1. Use SSH remote deployment, please refer to the www.cnblogs.com/JulianHuang…
  2. Based on docoer – compose complete Gitlab – ci, please refer to www.cnblogs.com/JulianHuang…
  3. If you are trying to mirror a Git branch, keep both the branch name and the snapshot of the commit action.

    We tried using both the branch name and CommitId as the mirror Tag,

    So changeCI_COMMIT_REF_NAME=$CI_COMMIT_BRANCH.$CI_COMMIT_SHORT_SHA, as a mirror tag on each Job,

  1. The jobs to be deployed later are frombuild.envReading mirror TAG

Docs.gitlab.com/ee/ci/varia…

K8s automatic deployment script

After Ssh remote login, the home directory of wd-deploy is accessed and the deployment script is executed.

Automatic deployment utilizes the native Kustomize command,

#! /bin/sh cd /home/wd-deploy/localdeploy/wd/overlays/ kustomize edit set image repository.gridsum.com:8443/eap/website=repository.gridsum.com:8443/eap/website:${TAG} kustomize build . | kubectl apply  -f -Copy the code

Kustomize Edit set image can instantly modify the kustomization. Yml file content, modify after the application, played a deployment effect!

The above is a complete DevOPS process for integration test environment —-> package image for release branch to alpha environment (there are operations) > Automatic deployment tag for production. .

If you have details, welcome to inquire!