Software Deployment Schedule

This list assumes software that runs from a server environment. This list also assumes deployments that do not require alteration of the underlying system or application-server software, for which we need to make more careful arrangements.

  • Production and Staging Systems: Software deployments must be scheduled for Tuesday or Wednesday evenings between 6:00 and 9:00 pm.
  • Production and Staging Systems: Software deployments must be emailed to isda-ops@mit.edu with at least 24 hours notice.
  • Test Systems: Software deployments are made during normal support hours, 8am to 6pm.
  • Test Systems: Software deployments requests must be made to isda-ops@mit.edu with at least 2 hours notice.
  • Development Systems: Software developers are entitled to sufficient rights to deploy software to development environments.

System Access Rules 

  • Only operational staff in IPS have permanent access to any non-development system. Operational staff in ISDA are defined by membership in the isda-ops@mit.edu mailing list. We include the members of OIS Server Operations.
  • Operational staff perform all software deployments to any non-prototype or non-development environment, regardless of who else has temporary access to the system at that time.
  • IPS System Programmers will be given temporary access to test environments, or others, as needed to troubleshoot discreet problems or assist with operations work.
  • Only operational staff and System Programmers have root access to prototype and development servers.

Checklist to be completed for a deploy to Production or Staging servers


 1.  Email isda-ops@mit.edu at least 24 hours in advance of a deploy window to
    schedule a deploy.  There are 2 deploy windows each week, on Tuesday and
    Wednesday night, between 6 pm and 9pm.  This email must include a manifest
    of webapps and related files that will be deployed or changed in the deploy
    process, and the location where the ISDA technician can acquire them.  
    Sending them as attachments, or pointing to a repository accessible to ISDA
    Ops is satisfactory.  Instructions on edits to any relevant file, or
    additional tasks to be performed as part of the deploy, must also be
    included here.

2.  A return email will be sent telling you who the isda-ops technician you will
    be working is, which RT ticket this deploy is being tracked by, and
    confirming which deploy window your deploy will occur in.

3.  Email your customer base, with a CC: to isda-ops, at least 24 hours in
    advance to notify them of a scheduled outage.  If this is not done, deploy
    should be delayed by 24 hours for notice to be sent.

4.  The ISDA Ops technician will send an outage notification to
    isda-integrators and to ASST/OIS (server ops) with CC: to the requester  
    notifying them of a pending outage at least 24 hours in advance of a deploy
    related outage.

5.  The engineer from the requesting group and the ISDA-Ops technician should
    connect over IM in either the ISDA-Ops chat room, or through a private chat,
    over Jabber at the beginning of the deploy window.

6.  Once IM contact has been made, any relevant or effected data must be backed
    up to an archive on an ISDA archive machine.  Inability to backup this data
    will cause the deploy to be delayed to the next deploy window, pending
    correction of the problem with archiving.  If there is no such data, this
    step can be skipped.

7.  At this time, the service may either be shutdown, or webapp based services
    not requiring an Apache or Tomcat restart may be undeployed through the
    manager.

8.  The changes detailed in the email from section 1 are performed at
    this time, with the requesting groups engineer and the ISDA Ops technician
    verify performing each stop over IM/Jabber.

9.  If the deploy steps go well, the service, Apache, and/or Tomcat may be
    restarted.  Functionality tests are then performed by the requesting
    groups engineer and the ISDA Ops technician.

10.  Email that the deploy is completed is sent to isda-integrators and ASST/OIS
     by the ISDA Ops technician stating that the deploy is completed, and giving
     current status.

11.  Email is sent by the requesting groups engineer to their customer base that
     the deploy is completed, and giving current status.

12.  The ISDA Ops technician updates the RT queue ticket for this deploy with
     what was performed.

13.  Sign off from IM/Jabber.

14.  Monitor service, Apache, and Tomcat on the effected servers and containers
     for the following 24 hours, minimum.  After this period, if no problems are
     encountered, the RT ticket is updated with the current status and resolved
     by the ISDA technician.

  • No labels