|
|
| Line 1: |
Line 1: |
| − | = Release Closure =
| |
| − | When all components expected for a release have been delivered and all building, deployment and functional issues have been solved, the release can be considered closed and the components distributed.
| |
| | | | |
| − | In order to close the release, these preparatory steps must be performed:
| |
| − | # [[Role_Release_Manager|RMan]] sets the option "Include in searchers" of gCube Staging repository to ''false''
| |
| − | # [[BTRT|BTRT]] continuous build type is set to ''Release build''. In this way, BTRT will publish the artifacts of the next build into the gCube Release Repository.
| |
| − |
| |
| − |
| |
| − | When all artifacts are published on the gCube Release Repository - i.e., after a 100% successful ''Release build'' - (a single build should be needed):
| |
| − | # [[Role_Release_Manager|RMan]] updates the [[Software Integration and Distribution: Release Log|Release Log]]
| |
| − | # [[Role_Release_Manager|RMan]] creates the Release Notes page (using XML Release notes)
| |
| − | # [[Role_Release_Manager|RMan]] disables the [[BTRT|BTRT]] builds
| |
| − | # [[Role_Release_Manager|RMan]] open a ticket to generate release description to include in the distribution page
| |
| − | # [[Role_Release_Manager|RMan]] sets the option "Include in searchers" of gCube Staging repository to ''true''
| |
| − | # [[Role_Release_Manager|RMan]] closes all release tickets (PRT, SRT, CRT) associated with closed release: <code>{status: Under Integration -> Released}</code>. In case a component has been excluded from the release (e.g. unsolved integration issues, delays in the delivery) the CRT is udpdated with status ''Removed'' <code>{status: Under Integration -> Removed}</code>
| |
| − | # [[Role_Release_Manager|RMan]] creates a tag svn for the entire released code
| |
| − | <span style ='color:red'>Below the NEW LINE for the deploy and testing management</span>
| |
| − | # Portal Manager or Preprod Infrastructure Manager :update the CRT <code>{status: Released -> RTD on Preprod}</code>.It indicates that the component has been published on stagin nexus repository (by explicitly launching an ETICS build on the current release or because the night build succeeded, more details in '''STAGING NOTE''').This is used to notify the portal manager or the preprod infrastructure manager to upgrade that component on preprod, in this case they MUST be added in advance as watcher of the component release ticket (more details in '''PROVISIONING NOTE'''). This status MUST not be used for subsystem release ticket or the master release ticket.
| |
| − | When the developer can update on preproduction the component autonomously it uses directly the Deployed on Preprod status.
| |
| − | # Deployer or Pre-Prod Infrastructure Manager updates the CRT <code>{status: RTD on Preprod -> Deployed on Preprod}</code>. It : Indicate that the component has been deployed on ALL nodes of preproduction and is up and running.
| |
| − | # Tester Manager updates the CRT <code>{status: Deployed on Preprod -> Tested on Preprod}</code> . The developer and/or the portal manager or the preprod infrastructure manager are confident that the component behave as expected and can be released as is.
| |
| − |
| |
| − | <pre>STAGING NOTE
| |
| − |
| |
| − | In the nexus configuration is added the build number on staging repository.
| |
| − | Developers, Deployer and/or pre-prod Infrastructure Manager must download the component to deploy
| |
| − | (both in dev and pre-prod infrastructure) , from Nexus repository, having the build number.
| |
| − | </pre>
| |
| − |
| |
| − | <pre>PROVISIONING NOTE
| |
| − |
| |
| − | When the deployment of a component involve more than two nodes, an automatic procedure
| |
| − | by using provisioning (ANSIBLE) MUST be created in advance.
| |
| − | The first time this situation is verified, the developer MUST create a ticket for provisioning support.
| |
| − | The ticket for provisioning MUST be related to the release ticket. The ticket can only be closed when
| |
| − | (all the bullet must be verified):
| |
| − |
| |
| − | * the provisioning script has completed (by the developer or by the entitled people);
| |
| − |
| |
| − | * a documentation regarding the script has to be created;
| |
| − |
| |
| − | * the ticket has been updated indicating where the provisioning script is available and where is the documentation.
| |
| − |
| |
| − | Only when the provisioning ticket is closed the RTD on Preprod status can be set.
| |
| − | </pre>
| |
