Under construction ...
| Gliffy Diagram |
|---|
|
TriggersStart points:
- T1S1: New version of the Seamless Access software
The development team publishes a new release version of the Seamless Access software, which was formerly approved according to the Release and Deployment process. Release notes of new versions of the software are available at https://thiss-js.readthedocs.io/en/latest/releasenotes.html - T2S2: Changes of the infrastructure
The operations team SUNET NOC may initiate changes by themeself. This applies to major changes which have a potential impact on the service, and therefore can not be handled as a standard change. - T3S3: Regular updates of the infrastructure
The operating team SUNET NOC performs regular updates of the underlying infrastructure, operating system and dependent software. These minor changes may be deployed using an shortened change process. Since these changes are very trivial, they are considered as pre approved.
Tasks:
- CM 01: The dev team updates the release manual according to the SA development prepares new release and deploys it as described (in the manual) to the Test Environment. Engineering team assists in this process in order to prepare the devops resources. updates the release manual.
- CM 02: Functional and quality tests are performed by the development team.SA development does software testing - such as functional and quality testing.
- 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.
- in thiss repository at GitHub, and Release manual updated.
- CM 04: SUNET engineering assists dev team by preparing the resources needed for deployment.
- CM 05 : SA development, with assistance of SUNET engineering, deploys the release at https://staging.thiss.io
- CM 06: Service operational manager creates Request for Change (RfC Template) and submits it to the SUNET engineering by creating ticket at SUNET JIRA. This step is also considered to be implicit change approval.
- CM 07: Service operational manager approves S2 type of change, initiated by the SUNET NOC.
- CM 08: Based on the RfC, SUNET engineering plans the change, the times of deployment and updates the ticket in SUNET JIRA. Changes with "Highest" priority are executed as soon as possible. All other changes are executed in next regular maintenance window.
- CM 09: Changes are deployed to the https://use.thiss.io according to the release manual using the defined release version from GitHub and, if applicable, docker images, puppet configs and other artefacts prepared during deployment at staging. JIRA ticket is updated. Start/stop the maintenance window in status.io.
- CM 10CM 08: Smoke tests are performed using the IA Test Tool SA monitoring. The test server deployment has to be monitored for at least 24 hours before T1 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 Seamless Access the IA Service Manager will be notified. JIRA ticket is updated.
- 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.
- 11: Previous docker image is used to roll back to previous state. JIRA ticket is updated.
- CM 12: Repeat CM10
- CM13: Service Operational Manager creates Request for Change (RfC Template) and submits it to the SUNET engineering by creating ticket at SUNET JIRA. This step is also considered to be implicit change approval.
- CM 14: Based on the RfC, SUNET engineering plans the change, the times of deployment and updates the ticket in SUNET JIRA. Changes with "Highest" priority are executed as soon as possible. All other changes are executed in next regular maintenance window.
- CM 15: Changes are deployed to the https://service.seamlessaccess.org according to the release manual using the defined release version from GitHub and, if applicable, docker images, puppet configs and other artefacts prepared during deployment at staging. JIRA ticket is updated. Start/stop the maintenance window in status.io.
- CM 16: Repeat CM10
- CM 17: Previous docker image is used to roll back to previous state. JIRA ticket is updated.
- CM 18: Repeat CM10
- CM19: Update and close the JIRA ticket.
Instructions for RfC Template, Message for the slack channel and how to announce maintanence on status.io is described at Seamless Access Change Management Instructions