Difference between revisions of "Release Integration"

From Gcube Wiki
Jump to: navigation, search
(Release Integration)
(Release Preparation)
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Release Preparation =
+
= Preliminary steps =
 +
 
 +
In order to develop a new component for gCube, the developer must perform the following steps:
  
In order to integrate a new component in a gCube release, some '''preparatory steps''' (performed by the Developer) are needed:
+
* Make sure the maven-parent '''1.1.0''' is used as parent pom
* Upgrade and test the component in development environment
+
* Upgrade and test the component in the development environment
 
* Deploy the SNAPSHOT version on gcube-snapshots repository
 
* Deploy the SNAPSHOT version on gcube-snapshots repository
* Add the maven-parent 1.1.0 to the component pom
+
* Make sure the Git repository of the component is set up with a  working [https://wiki.gcube-system.org/gcube/Gitea/Jenkins:_Setting_up_Webhooks CI webhook]
 +
* Make sure the [https://wiki.gcube-system.org/gcube/Cloning_Git_Repository#Set_up_the_SCM_Connection scm section] is present in your pom
  
 +
= Release Preparation =
 +
In order to prepare a new component for the integration within a gCube release, the developer must perform the following steps:
  
 +
* Align the component's repo content to the templates defined here: https://code-repo.d4science.org/gCubeCI/Templates/src/branch/master/gCubeComponents
 +
** '''IMPORTANT''': the CHANGELOG.md file must have a section that 'tags' the work done in the current release. This tag is expected in the format '[v<version>] - <date>'. See the [https://code-repo.d4science.org/gCubeCI/Templates/src/branch/master/gCubeComponents/CHANGELOG.md CHANGELOG.md  ] template.
 +
* Remove the -SNAPSHOT postfix from the version in the pom on the master branch
 +
* Make sure the related JenkinsJob is pointing to the master branch
 +
* Create a new subticket of "gCube Release Next" defined here: https://support.d4science.org/issues/17579
 +
** The subject ticket must uniquely identify the component
 +
** When the all these steps have been completed the ticket can be set to ''Available'' state.
  
 +
Then, the '''Release Manager''' is in charge to add all the ''Available'' tickets to the new Release and the '''integration phase''' of the  release can start.
  
= Release Integration =
+
*During the integration phase, the master branch of each component under release must be frozen until the release is declared closed by Release Manager. As per feature branching policy, any work must be performed in a separate feature or fix branch.
Once the preparation steps are completed, the integration phase can be started.
+
 
+
The rules to attach a component to a new gCube Release are the following ones:
+
 
+
* Align the component to the gCubeTemplate defined here: https://code-repo.d4science.org/gCubeCI/Templates/src/branch/master/gCubeComponents
+
** remember that the CHANGELOG.md file must have the current release tag and the current version tag
+
* Remove the snapshot from the master branch
+
* Create a new subticket of gCube Release Next master ticket: https://support.d4science.org/issues/17579
+
** The subject ticket must uniquely identify the component
+
* When the previos steps are completed the ticket can be set to Available state. The Release Manager is in charge of add all the Available ticket to the new Release.
+

Latest revision as of 16:01, 4 May 2022

Preliminary steps

In order to develop a new component for gCube, the developer must perform the following steps:

  • Make sure the maven-parent 1.1.0 is used as parent pom
  • Upgrade and test the component in the development environment
  • Deploy the SNAPSHOT version on gcube-snapshots repository
  • Make sure the Git repository of the component is set up with a working CI webhook
  • Make sure the scm section is present in your pom

Release Preparation

In order to prepare a new component for the integration within a gCube release, the developer must perform the following steps:

  • Align the component's repo content to the templates defined here: https://code-repo.d4science.org/gCubeCI/Templates/src/branch/master/gCubeComponents
    • IMPORTANT: the CHANGELOG.md file must have a section that 'tags' the work done in the current release. This tag is expected in the format '[v<version>] - <date>'. See the CHANGELOG.md template.
  • Remove the -SNAPSHOT postfix from the version in the pom on the master branch
  • Make sure the related JenkinsJob is pointing to the master branch
  • Create a new subticket of "gCube Release Next" defined here: https://support.d4science.org/issues/17579
    • The subject ticket must uniquely identify the component
    • When the all these steps have been completed the ticket can be set to Available state.

Then, the Release Manager is in charge to add all the Available tickets to the new Release and the integration phase of the release can start.

  • During the integration phase, the master branch of each component under release must be frozen until the release is declared closed by Release Manager. As per feature branching policy, any work must be performed in a separate feature or fix branch.