Under construction ... 

Triggers:

• T1: 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.
• T2: Changes of the infrastructure
  The operations team 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.
• T3: Regular updates of the infrastructure
  The operating team 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: SA development prepares new release and updates the release manual.
• CM 02: SA development does software testing - such as functional and quality testing. 
• CM 03: The release version of the software is tagged 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 owner creates Request for Change and submits it to the SUNET engineering by creating ticket at SUNET JIRA.  (- RfC Template). This step is also considered to be implicit change approval. 
• CM 07: Service Owner approves T2 type of change, initiated by the SUNET NOC.
• CM 08: Based on the RfC, SUNET engineering plans the change and updates the ticket in SUNET JIRA.
• CM 09: Changes are deployed to the test server according to the release cookbook using the defined release version from GitHub and prepared docker images, puppet configs etc.
• CM 10: 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 Seamless Access the Service Manager will be notified.
• CM 11: 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.

RfC

Each RfC shall contain the following attributes:

• Service Name: InAcademia
• (NDN Service ID / Customer ID)?
• Change Type: Software / Infrastructure / Other
• Priority: Standard / Emergency
• Time schedule: Suggested time frame for the Change to be implemented
• Description: Summary of the Change
• Customers Affected: Customers affected by change