Versions Compared

Old Version 32

changes.mady.by.user Marina Adomeit

Saved on

compared with

New Version Current

changes.mady.by.user Marina Adomeit

Saved on

Key

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

...

Gliffy Diagram
nameSeamless Access Change Management Process v2.1
pagePin272

Start points:

  • S1: 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 
  • S2: Changes of the infrastructure
     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.
  • S3: Regular updates of the infrastructure
    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.

...

  • 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 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 Owner 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 10: Smoke tests are performed using the SA monitoring. The deployment has to be monitored for T1 proceeding with the change workflow. In case of any issues and if the change was initiated by Seamless Access the Service Manager will be notified. JIRA ticket is updated.
  • CM 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 15CM 13: 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 1416: Repeat CM10
  • CM 1517: Previous docker image is used to roll back to previous state. JIRA ticket is updated.
  • CM 1618: Repeat CM10
  • CM17CM19: Update and close the JIRA ticket.  

RfC Template

Each RfC is JIRA ticket raised in SUNET JIRA with following attributes:

  • Project: SeamlessAccess(SA)
  • Issue Type: Change
  • Summary: Change Type [Software / Infrastructure / Standard], and summary of the change 
  • Description:
    • Describe in more detail what the change is about.
    • Summary of the change.
    • Suggest time frame for the Change to be implemented. Define T1 and T2.
    • Describe which customers the change is affecting and wether it is potentially disruptive.
  • Priority: Highest for emergency/security changes, Medium for software and infrastructure changes, Lowest for standard changes
  • Schedule: Define schedule for release to beta and production environment


Instructions for RfC Template, Message for the slack channel

Release to demo/beta site

Hi all! We are planning to deploy new releases of thiss.js and thiss.mdq software to the Thiss Demo site (use.thiss.io).
New releases contain fixes for: 

Have a look at https://status.seamlessaccess.org/ maintenance announcement for more info. 
Please take this opportunity to test the new software release with your deployments, as we are planning for production deployment relatively soon. Please let us know if you find any issue or you have questions about the new release.
Information about planned release to production service is soon to follow.

Maintenance window on slack.io 

Set automatic start and end:  1,5h for normal changes i.e. deployment of new software version.and how to announce maintanence on status.io is described at Seamless Access Change Management Instructions