Skip to content

Instantly share code, notes, and snippets.

@manchuck

manchuck/New Dynamx Deploy Procedure.md

Last active December 22, 2015 06:09
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save manchuck/84c0f83ce79fb06f9e79 to your computer and use it in GitHub Desktop.
Save manchuck/84c0f83ce79fb06f9e79 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
New Dynamx Deploy Procedure.md

New Dynamx Deployment Procedure

This document described the deployment procedure for New Dynamx.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Definitions

This section defines terms that will be used throughout this document

  1. Feature - functionality that has been defined in the current release cycle.
    This can include but is not limited too:
    • Changing Design
    • Adding new static pages
    • Creating a new connection to third party
    • Adding support for a new browser version
    • Template changes that require Database and/or Code changes
  2. Bug (Bug Fix) - a feature or functionality that has been defined in previous release cycle that does not function. Bugs are classified as folows:
    • Framework issue This bug exists due to a code base that is not under New Dynamx control. A bug that falls in this category MAY NOT be able to be resolved by New Dynamx
    • Feature Defect This bug came about due to a new feature
    • Regressed Defect This bug was corrected in a previous release but has reappeared in this release cycle
  3. Release Cycle - a predefined list of Features and or Defects that have been agreed to be added/resolved during a development period. The development period is set into Milestones that will have a sign off between New Dynamx and the Project Owner
  4. Milestone (Phase) - A phase of a release where development is taking place
  5. Project Owner - A client of New Dynamx that is asking for work to be complete
  6. Semantic Versioning - A system to identify version numbers for code compatibility
  7. Production server - the server environment where the end user can access the application
  8. Staging Server - the server environment where the Project Owner can perform Acceptance and Intergration testing (see Cycles below)
  9. Code Freeze - a state where no changes can be introduced. This includes but is not limited to:
    • Template Changes
    • Database Schema changes (NOTE: database content can be changed)
    • Code changes

Development Milestones

Milestones dates will be created by New Dynamx. Dates between Milestones MUST be between 1 and 10 business days (1 to 2 weeks). Once milestone dates have been agreed upon between Project Owner and New Dynamx, the development cycle will be considered "Locked". While a Release Cycle is locked, new features and bugs that are considered a Framework Issue SHALL NOT be added to this release.

Milestones

Development

Development is the period where New Dynamx will work on all features and bug fixes defined in the release cycle

Acceptance Testing

Once development is completed, New Dynamx will tag all features into a Minor or Major release (see Semantic Versioning). Code will then be deployed to a staging server for Project Owner to begin testing changes and accept the release. During acceptance testing it is RECOMMENDED that design changes on the Production Sever are limited to avoid issues during integration testing. If during acceptance testing a new bug is descoverd that is not a Framework Issue and can be completed before the end date of this milestone, New Dynamx will create a Patch release and acceptance testing will start over

Integration Testing

After Project Owner has signed off acceptance testing, New Dynamx will implment code freeze. New Dynamx will then pull down existing templates into the release and create a Patch. The database from the production server will be merged to the staging server. New Dynamx and Project Owner will then confirm that new features will function with current data. Only regressed bugs can be resolved during this milestone. This milestone SHOULD NOT last more than 2 business days

Deploy

Deployment involves moving the code base from the staging server to production server this phase will only be allowed between the hours of 10 AM and 3 PM EST Monday through Wednesday. This restriction is in place to ensure stability of project during limited availability during weekend hours. The project owner can request a OPTIONAL maintenance page to be displayed during the deploy phase only if the process is expected to last longer than 5 minutes or if transferring to a new production server. A representative from project owner is REQUIRED to be avialable to ensure a successful deployment. The representative will have the authority to rollback to the previous release. Decision to roll back MUST BE made with in 1 hour of notification of deployment. If a decision to roll back is not made, then any bugs will then be subject to HOT FIX rules or applied to a new release

HOT FIX

This is a smaller release cycle that fixes a critical a bug that cannot wait for a complete release cycle. This release cycle MUST NOT last more that 1 business day. It is RECOMMENDED that only 1 bug be addressed during each HOT FIX. A HOT FIX will also delay any milestones in the next release cycle by 1 day.

The following criteria MUST BE met in order to consider a bug as critial worthy of a HOT FIX

  1. 10% or more of End Users/Customers or revenue affected
  2. MUST BE functional only (unless affected by 10% rule)
  3. No workaround exists. Examples of a workaround:
    • Use different browser
    • Use alternative hardware (iPad, desktop, OS)
    • Manual input time greater than Development time
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment