Build and Release

A continuous learner for experience and life.

Continuous Integration/Delivery Pipeline

enter image description here

Based on several software release engineering system, such as: Jenkins (include a bunch of Plugins), Gerrit, Git, Mocha, Nodejs and etc, we create a continuous integration pipeline to control source code, validation change(s), build artifact, report test results and deploy the artifacts to various deployment servers, just as: dev, staging, production (all groups). Here is a draft diagram we are trying to implement for Content Stream Application Service:

Continuous Integration Pipeline

Here are some explanations for a specific job of content stream, for example:

  • The job contentstream-patchset will be triggered automatically when one change is being pushed to Gerrit for review, it will set verify bit ‘+1’ for the review if the build successfully; or warn the submitter of the change if the build fail;
  • When any change is merged to the branch, for example, ‘master’, the job contentstream-master will be triggered automatically to verify the change if it affects the branch;
  • The job contentstream-master-release is to make tag, push the tag to server to label a version of source code, which should be deployed to deployment servers some time later;
  • The deployment jobs, like contentstream-master-deploy-to-* will deploy the source code to the dev|stag|prod (group1, group2, …) servers according to the version which labeled on the release job as above;

Written with StackEdit.

Comments