Difference between revisions of "Continuous Integration of gCube System: Overview"
Manuele.simi (Talk | contribs) |
Manuele.simi (Talk | contribs) (→How many Builds) |
||
| Line 6: | Line 6: | ||
= How many Builds = | = 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. | + | 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. | 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. | ||
| Line 16: | Line 16: | ||
* the development of new features and bug fixing are done in dedicated branches ([[Branching_Strategy|task branching]]) | * the development of new features and bug fixing are done in dedicated branches ([[Branching_Strategy|task branching]]) | ||
* merges into master branch are performed when the feature/fix is stable | * 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 and consistent piece of working code | + | * 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 | * 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 [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ||
Revision as of 04:16, 13 May 2019
Workflow
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.
