EMI Release Check List

1. Introduction

The Release Check List summarises the steps to be followed to release a new version of an EMI software product. The list of EMI software products can be found in the DNA1.3.2 - Technical Development Plan [R19].

2. Summary

1. Are you planning to release immediate or high priority RfCs? In this case, get the RfCs approved by the EMT first. Make sure the XML file [R2] exporting information from your RfC tracker contains the RfCs you want to release and that they are included in the Metrics Report [R3] generated every week for the EMT.
2. Ask the Release Manager to create a release task in the EMI Release Tracker [R1]. The release task is then assigned to the corresponding PT. Release tasks can contain the following type of changes:
   • If the new product version is an update for a version already existing in a major EMI release:
     • Development tasks [R5] AND/OR High priority RfCs, BUT ALSO Medium or Low RfCs that may be already implemented and ready to be released.
     • Immediate RfCs ONLY.
   • If the new product version is a new version for a major EMI release
     • Development tasks [R5] AND/OR Medium or Low RfCs.
3. Do you know how to fill in a release task? Check the Change Management Policy [R4] and fill in the necessary fields.
4. FOR EACH RfC/development task you plan to release DO
   1. Attach it to the release task using the List of RfCs field.
   2. Move the corresponding development task status to Ongoing. Regularly update the task by defining the fields Planned to be finished and Percent complete and adding a comment summarising the progress.
   3. Implement the change and submit the new code into your VCS.
   4. Move the corresponding RfC status to Fixed or move the corresponding development task status to Done.
5. Have you finished implementing your changes? Then tag your code. Make sure before tagging, that the subsystem builds without errors:
   • For EMI major releases: in the development project configuration emi_B_X_dev.
   • For EMI updates: in the project configurations emi_R_X_rc and emi_R_X_prod.
6. Create a new ETICS configuration containing the new tag. Follow the Build Configuration and Integration Policy [R6] to know more about ETICS configurations and ETICS configuration name syntax.
7. Send the new ETICS configuration to the Release Manager so she adds it into the emi_R_X_rc project configuration, which is the project configuration containing all the new products scheduled for the release.
8. Check the nightly build results of emi_R_X_rc to make sure your ETICS configuration builds without errors.
9. Lock your ETICS configuration.
10. Register your packages by building your ETICS configuration against the emi_R_X_prod project configuration. Follow the Packaging Policy [R14] to know which package formats need to be provided.
11. Copy the package names in the release task. Note that only the packages owned by the PT in the component release should be included. You must include all supported package formats.
12. Do you have a Test plan for your product? Check the Testing Policy [R7] and use this Test Plan template [R15] to create a test plan for your product.
13. Add the URL to your Test Plan in the release task in the Test Plan Link field.
14. Add the URL to your Test Plan in the QC Test Plan [R8] twiki.
15. Test your software product:
    1. Deployment tests: deploy the new version of your product in your PT machines.
    2. System tests: in order to run some of the tests in your Test Plan, you may need to interact with the services deployed in the EMI Testbed [R9].
    3. WHILE there are RfCs in status Fixed DO
       • Make sure the RfC is properly implemented (there should be a test defined for that!)
       • Change the status to Tested or Not Tested (if you didn't have the means to verify the implemented RfC)
16. For development tasks, you should also make sure there's a test defined for it, and you have to make sure the implemented development task works as expected.
17. Write the TestReport [R10]. Make sure that at least the Summary section is provided in txt format and that the name of the Test Report contains the words test and report (no matter the case and the order).
18. Attach the Test Report [R10] in the release task.
19. Is your Minimum Required Documentation up to date? Check the Documentation Policy [R11] to know what needs to be included in each document.
20. Document the Release task:
    1. Release Notes: don't forget to mention whether the documentation has been updated or not.
    2. Links to Documentation: Add the links to at least the mandatory documentation for your product.
21. Certify that your release task has followed all SA2 policies by filling in the Certification Report [R12]. Make sure that the Certification Report is provided in txt format and that the name contains the words cert and report (no matter the case and the order).
22. Attach the Certification Report [R12] to the release task.
23. Move the status of the Release task to Certified.
24. QC checks the release task against the Production Release Criteria [R13].
25. QC attaches the verification report to the release task.
26. QC moves the Release task to Ready for Testbed if all mandatory criteria is OK. If not, the task is moved back to Open.
27. The Release Manager prepares the Testbed repository with the new packages.
28. The Release Manager opens a GGUS tickets for the EMI Testbed.
29. The Testbed Manager deploys and tests the new product version in the EMI Testbed.
30. The Testbed Manager moves the task to Deployed on Testbed once he finishes deploying and testing the new packages in the EMI Testbed. If the testing is successsful he also changes the field Testbed Result to PASS; Otherwise he changes the field Testbed Result to FAIL. If the deployment tests fail, the task is moved to Open.
31. QC checks the release task again for final details.
32. QC attaches a second verification report to the release task if needed.
33. QC moves the Release task to Verified.
34. If the Release Manager is happy with the QC report, she signs and copies the new packages into the Production repository, prepares the release pages and moves the release task to Released.
35. The PTs moves the corresponding RfCs to Closed.
36. PTB moves the corresponding development tasks to Closed.

3. Release Process in detail

3.1. Release task definition phase

PTs prepare a new version of a product when there are RfCs or development tasks assigned to them that need to be released. In the case of RfCs, PTs must take into account their priority:

• If the new product version is an update for a version already existing in a major EMI release, it can include:
  • Immediate priority RfCs. In this case, the release task can only contain other Immediate RfCs provided they don't delay the release that should be done as soon as possible.
  • High priority RfCs. In this case, the release task can also contain Medium or Low RfCs that may be already implemented and ready to be released.
• If the new product version is a new version for a major EMI release, it can include: Medium or Low RfCs.

Immediate and High priority RfCs need to be approved by the EMT before they can be actually included in a release task. A list of High and Immediate priority RfCs is presented every week at the EMT in the Metrics Report [R3]. This report takes the information from the RfC trackers using a set of XML files produced by the PTs. PTs must make sure the RfCs they want to release are included in the metrics report so that they can be approved in the EMT.

The Release Manager is responsible for creating a new release task in the EMI release tracker [R1]. The release task is then assigned to the corresponding PT.

The fields of the task that need to be filled in are described in the Change Management Policy [R4].

3.2. Coding phase

PTs work on the RfCs and development tasks implementation. For development tasks, as soon as they start working on the tasks, the status field should be updated to Ongoing. Until the task is finished, regular updates should be posted in the comment field of the task making sure the fields Planned to be finished and Percent complete are up-to-date.

A URL pointing to each RfC or development task must be included in the release task, in the field List of RfCs.

Once the new code is ready in the VCS, RfC status must be moved to Fixed (or the corresponding status name in the tracking system) and/or development task status must be moved to Done.

Note that in the case of RfCs, regardeless of their priority, once they are opened they must be Accepted or Rejected within a period of two weeks.

For more details, please check the Change Management Policy [R4].

3.3. Building and packaging phase

ETICS must be used to build EMI packages. An ETICS configuration for the new product version containing the corresponding VCS tag needs to be created. For more details, please check the Build Configuration and Integration Policy [R6].

Supported package formats are defined in the Packaging Policy [R14].

A metapackage containing only first level dependencies needs to be provided as well for those EMI products that need to install several dependencies.

The ETICS subsystem must build without errors and it must be locked to be able to register the packages in the ETICS repository

Once the packages are available in ETICS, update the Packages field of the release task (all supported formats must be included). Note that only the packages provided by the PT and which actually change in the release have to be added.

3.4. Testing phase

PTs must define a Test Plan for their software products. A Test Plan Template [R15] is provided as a reference. A link to the Test Plan must be included in the release task in the field Test Plan Link.

The Testing Policy [R7] must be followed to test new product versions.

At the end of the testing phase, a Test Report [R10] must be attached to the release task.

3.5. Documentation Phase

Documentation must follow the Documentation Policy [R11].

The following fields must be filled in in the release task:

• Documentation: Link to the relevant documentation, at least including the mandatory documentation for the product according to the Documentation Policy.
• Release Notes: non-technical text written in good english giving an overview of the change introduced by the packages. The text should be prepared by the PT responsible for the product. It should contain the following structure:
  • What's new: Brief description of the main changes, both new features and bug fixes, and also Documentation Changes.
  • Installation and configuration: More details on installation and configuration stating very clearly if the service must be reconfigured and/or restarted.
  • Know issues: Known issues present in the release, possibly with a workaround.
• Extended Release Notes: This is an optional field where you can include a URL in case you are also maintaining the release notes in an internal twiki page.

3.6. Certification phase

The Certification Policy [R16] must be followed to certify the new product version.

A Certification Report [R12] must be attached to the release task.

The release task status should be then moved to Certified.

3.7. FIrst QC verification phase

The certification report is checked by QC. A verification report [R17] is attached to the release task at the end of this phase.

Taking into account the Production Release Criteria [R13], QC moves the task to Ready for Testbed if all the mandatory checks are OK. If mandatory checks fail, the task is moved back to Open.

Minor improvements may be suggested by QC in the release task so that the PT can provide missing information in the upcoming days, while the release process continues.

3.8. Testbed deployment phase

The release manager populates the release candidate repository with the packages of the release tasks in status Certified.

The release manager informs EMI Testbeds that new product versions are ready to be deployed using a GGUS ticket.

EMI Testbeds deploys the new product versions in the testbed and runs tests for one week. Deployment, functionality and inter-component tests are run.

EMI Testbeds moves the release task to Deployed on Testbed if the testing is successsful. The release task field Testbed Result is also updated to PASS; Otherwise the release task is moved to Open and the field Testbed Result is updated to FAIL.

3.9. Second QC verification phase

QC does a final check of the certification report. If needed, a new verification report [R17] is provided.

Taking into account the Production Release Criteria [R13], QC moves the task to Verified if all the mandatory checks are OK. If mandatory checks fail, the task is moved back to Open.

3.10. Release phase

The release manager signs the packages from Verified tasks, and moves them from the the release candidate repository into the EMI Production repository.

The corresponding release tasks are moved to Released.

PTs should then close the associated RfCs in the corresponding trackers.

PTB should then close the associated development tasks in the Development Tracker [R5].

4. Release Candidates for EMI major releases

A Release Candidate (RC) approach is followed for EMI major releases. Details can be found in:

• EMI 1 Release Schedule
• EMI 2 Release Schedule

As far as the release process is concerned, check the table and the information below to understand how it has to be applied for each RC.

(1) - It can be the same for all RCs

(2) - Only if PTs have successfully deployed their products "in-house".

Please, also note that:

• The same task must be used for all RCs and fields can be overwritten if their value change from one RC to another.
• The task should be moved to Certified only when all the required artifacts are available (see table). Otherwise, don't change the state from one RC to another.
• Testbed Deployment will happen in all RCs but only in the last RC the task state will be updated to Deployed on Testbed.
• Verification will happen only in the last RC (unless the PT certifies the task before).

5. Contacts

EMI SA2

6. Table of References

Reference	URL
R1	EMI Release Tracker https://savannah.cern.ch/task/?group=emi-releases
R2	EMI Persistent Bug Tracking Collection https://twiki.cern.ch/twiki /bin/view/EMI/EmiSa2MetricsGuidelines#Persistent_Bug_Tracking_Collecti
R3	EMI EMT Metrics Report http://emiqa.web.cern.ch/emiqa/
R4	EMI Change Management Policy https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ChangePolicy
R5	EMI Development Tracker https://savannah.cern.ch/task/?group=emi-dev
R6	EMI Configuration and Integration Policy [https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2ConfigurationIntegrationPolicy
R7	EMI Testing Policy [[https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2TestPolicy
R8	EMI Test Plans https://twiki.cern.ch/twiki/bin/view/EMI/QCTestPlan
R9	EMI Testbed https://twiki.cern.ch/twiki/bin/view/EMI/TestBed
R10	EMI Test Report Template https://twiki.cern.ch/twiki/bin/view/EMI/EMITestReport
R11	EMI Documentation Policy https://twiki.cern.ch/twiki/bin/view/EMI/EMISa2DocumentationPolicy
R12	EMI Certification Report Template https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2CertPolicy
R13	EMI Production Release Criteria https://twiki.cern.ch/twiki/bin/view/EMI/ProductionReleaseCriteria
R14	EMI Packaging Policy https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2PackagingPolicy
R15	EMI Test Plan Template https://twiki.cern.ch/twiki/bin/view/EMI/EMITestPlan
R16	EMI Certification Policy https://twiki.cern.ch/twiki/bin/view/EMI/EmiSa2CertPolicy
R17	EMI Verification Report https://twiki.cern.ch/twiki/bin/view/EMI/EMIQCVerificationReport
R18	DNA1.3.2 - Technical Development Plan https://twiki.cern.ch/twiki/pub/EMI/DeliverableDNA132

7. Logbook

Details Hide Details