EMI Release Check List

Latest approved version of this document
15.09.2011: EMI_SA2_ReleaseCheckList_v_3_1.pdf
Quick links
Test Report template
Certification Report Template

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
  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:

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.

  RC0 RC1 RC2 RC3 RC4 Comments
CVS Tag   x x x x (1)
ETICS Subsystem x x x x x  
Binary rpms   x x x x  
Binary tarballs   x x x x  
Source rpms     x x x  
Source tarballs     x x x  
Test Plan   x x x x  
Fixed RfCs   x x x x  
Test Report   x x x x  
Documentation         x  
Release Notes   x x x x  
Certification Report         x  
Testbed update x x x x x (2)
QC validation Report         x  
Documentation Review         x  

(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

v3.2

  • 06.02.2012: Added EMI2 Schedule link.

v3.1

  • 15.09.2001: Added details on development tasks fields and status.
  • 05.09.2011: Remove that development tasks should appear in the Dependencies section of the release task. Added that they should be included in the List of RfCs field instead.

v3.0

  • 25.08.2011: add section numbers, add table of references, reorganise.
  • 22.08.2011:
    • Rename Testbed Deployed to Deployed on Testbed.
    • Add development tasks at the same level as RfCs.
  • 08.08.2011:
    • Added the type of RfCs that can ne released in an update/new major release Release Task.
    • Added relevant sections for the new Ready for Testbed state.
    • Removed the emi-sherpa task snapshot.
  • 13.07.2011:
    • Change component release (CR) with release task which is a more clear and appropriate term.
    • Reorganise the steps and the relevant sections to include the testbed deployment just after the certification of the task.
  • 29.06.2011:
    • Added references to new release manager mail address.
    • Added Joni's feedback to make a difference between the project configurations used for major releases and updates.
    • Changed 1 with X in all references to project configurations in ETICS to make it valid for any EMI release.
  • 15.06.2011:
    • Use product instead of component where applicable.
    • Changed references to th different ETICS configurations as requested by Cristina: emi_B_1_prod => emi_R_1_prod, emi_B_1_rc => emi_R_1_rc, emi_1_dev => emi_B_1_dev.
    • Explained that changes need to be discussed and approved first with release manager.
    • Removed complete URL for package names.
    • Removed list of mandatory documentation since this will be defined per type of product.
    • Removed the part that makes reference to inter-component testing since testbed deployment details are not included in this twiki.
    • Updated RC section.

v2.0

  • 25.03.2011: Changes to comply with the documentation policy.
  • 18.03.2011: Added a table for artifacts to be provided in the different RCs.
  • 07.02.2011:
    • Minor improvements clarifying steps after feedback from training.
    • Move the QC report to the Production Criteria twiki.

v1.0

  • 28th February 2011 : First version of the check list approved by PEB.

Topic attachments
I Attachment History Action Size Date Who Comment
PDFpdf EMI_SA2_Checklist_v_1_0.pdf r1 manage 589.1 K 2011-03-07 - 15:36 MariaALANDESPRADILLO  
PDFpdf EMI_SA2_ReleaseChecklist_v_3_0.pdf r1 manage 531.7 K 2011-08-25 - 13:40 MariaALANDESPRADILLO  
PDFpdf EMI_SA2_ReleaseChecklist_v_3_1.pdf r1 manage 434.7 K 2011-09-15 - 16:09 MariaALANDESPRADILLO  
GIFgif checklist_CR_savannah.gif r4 r3 r2 r1 manage 244.6 K 2011-03-01 - 16:53 MariaALANDESPRADILLO  
JPEGjpg checklist_diagram.jpg r1 manage 470.2 K 2011-02-17 - 17:57 MariaALANDESPRADILLO  
JPEGjpg checklist_diagram_v2.jpg r2 r1 manage 543.8 K 2011-03-02 - 11:34 MariaALANDESPRADILLO  
Edit | Attach | Watch | Print version | History: r41 < r40 < r39 < r38 < r37 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r41 - 2012-02-06 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback