Difference between revisions of "Continuous Integration of gCube System: Overview"

From Gcube Wiki
Jump to: navigation, search
(How many Builds)
(How many Builds)
Line 21: Line 21:
 
By following them, builds are triggered only when a stable feature is merge into master, while commits in the other branches do not involve Jenkins. If two branches are built at the same time in a Jenkins project (which should be temporary), their different versions guarantee that there are no conflict in the published artifacts.
 
By following them, builds are triggered only when a stable feature is merge into master, while commits in the other branches do not involve Jenkins. If two branches are built at the same time in a Jenkins project (which should be temporary), their different versions guarantee that there are no conflict in the published artifacts.
  
More suggestions for a proper exploitation of the pipeline are in the [[CI_Best_practices|Best Practice]] section.
+
More suggestions for a proper exploitation of the pipeline are in the [[Continuous_Integration:_Best_Practices|Best Practice]] section.
  
 
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].''
 
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].''

Revision as of 03:23, 13 May 2019

Workflow

CI pipeline V6.png

How many Builds

The biggest risk of a non-properly configured Continuous Integration pipeline is to trigger too many builds and transform the pipeline into something we can call Continuous Building. Parallel builds of the same project that interfere with each other and may create inconsistent situations are very common. For instance, this is the case when each commit is immediately to the master branch or when the Git repository is wrongly used as backup system.

In this guide, we set up a few procedures to prevent this misbehavior. Some of them assume a proper usage of Git from the user.

Here's a summary of these practices:

  • the Jenkins project builds always the master branch
  • if a Jenkins project is configured to build a second branch, this branch must generate a software artifact with a different version than master branch
  • the development of new features and bug fixing are done in dedicated branches (task branching)
  • merges into master branch are performed when the feature/fix is stable
  • commits are not always pushed to the remote repository, but only when they add a significant, self-contained and consistent piece of working code
  • the master branch MUST be always in a releasable state

By following them, builds are triggered only when a stable feature is merge into master, while commits in the other branches do not involve Jenkins. If two branches are built at the same time in a Jenkins project (which should be temporary), their different versions guarantee that there are no conflict in the published artifacts.

More suggestions for a proper exploitation of the pipeline are in the Best Practice section.

Back to the CI guide.