Versions Compared

Old Version 2

changes.mady.by.user Marina Adomeit

Saved on

compared with

New Version 3

changes.mady.by.user Marina Adomeit

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • CM 01: The dev team updates the release cookbook manual according to the new release and deploys it as described (in the cookbook) to the development test server.manual) to the Test Environment. Engineering team assists in this process in order to prepare the devops resources. 
  • CM 02: Functional and quality tests are performed by the development team.
  • CM 03: The release version of the software is tagged in DockerHub and the release cookbook is published in the OPS wiki.
  • CM 04: A Request for Change is created and submitted to the NDN support either via email or JIRA by the IA Service Manager (- RfC Template).
  • CM 05: Based on the RfC the change is planned and details are published in JIRA by the NDN support.
  • CM 06: The IA Service Manager has to approve each change (via GitHub or email) before it will be processed by NDN. Approved (major) changes may be announced to the customers.
  • CM 07: Changes are deployed to the test server according to the release cookbook using the defined release version from DockerHub.
  • CM 08: Smoke tests are performed using the IA Test Tool. The test server has to be monitored for at least 24 hours before proceeding with the change workflow. During this time the development team may use the service for manual tests. In case of any issues and if the change was initiated by InAcademia the IA Service Manager will be notified.
  • CM 09: In case of a major change, a snapshot of the current VM state is created and stored for backup.
  • CM 10: The change is fully deployed firstly to all TIER2 nodes and monitored during a probation period no shorter than one hour and no longer than 6 hours.
  • CM 11: If functional errors are experienced on TIER2 nodes these nodes will be rollbacked to previous software versions. No deployment on TIER1 will occur. Change workflow will jump to point CM 14.
  • CM 12: The change will be deployed on TIER1 nodes. The server has to be monitored for at least 24 hours before proceeding with the change workflow.
  • CM 13: If the change causes any issues during the monitoring period a rollback will be performed (e.g. revert data, re-deploy the former InAcademia version or using a snapshot available).
  • CM 14: The change created in JIRA will be updated or closed.