Starkey Foundation - Starkey Video : Server Deployments

This page last changed on Jun 03, 2014 by pablo.viquez.

Main Navigation

Home

Home - Development

Home - Discovery & Architectur- e

Home - Servers & Sysadmin

Home - Starkey Teaser

Servers & Sysadmin Navigation

Home - Servers & Sysadmin

Operation Change Production

Production Benchmarks

QA & Staging Server

Server Deployments

[Staging Server Architectur- e- Configurati- on -Deployment](/display/STARKEYV ID/Staging+Server+Architecture-+Configuration+-Deployment)

System Reqs

Intro & Context

The software versioning control that we currently use can have different branches of development, so people can work in different features or versions without disturbing servers or their team mates.

SVN Terminology

Trunk

This is the main development "branch", all code committed here should be tested, and it's still considered unstable this because code is being committed all the time with new features and work in progress functionality

Branches

These are different streams of work

Tags

Code snapshots in time. Another explanation is a picture of the code in certain moment. These snapshots cannot be changed, so if you need to add something that was missing on the tag you created, the approach is to create a new tag instead.

Current Workflow

As 2014-06-03
Right now all development happens in trunk (good and how it should be), however QA also points to trunk, therefore QA code is not actually quite stable; to make a point here, most of the errors we have had are related to content and not to code.

The problem we have having this setup is that if a developer starts doing tests in QA, and another developer is working finishing up a feature, the QA tester cannot verify for sure that the error is inked to a particular version since in 5 minutes the issue can go away.

Proposed Workflow

QA to Staging

1. Once the code is stable and is ready for production, a new tag should be created out of the current working branch; normally the tag will include the a minor revision like: v1.0.0
2. Backup production (3 DB backup files) 1. CMS Content 2. User information (points, logs etc) 3. Full DB Backup
3. Import the entire production content into Staging
4. Sync images from production into staging 1. Images should be on a different directory so they do not have conflicts with code exports
5. Apply the fixes or new code 1. Import CMS data if required 2. Fix paths and urls for staging using a PHP script 3. Sync images from QA 4. Restart the services only if required
6. Do a smoke test 1. Using Jmeter, test that all CMS API endpoints are available compliant 2. Also, with Jmeter, test that the API frontend works and the pages are responding
7. If everything went well, we can have a green light that the code works.

Staging to Production

Code Release Only

1. Backup production and staging (3 DB backup files per instance) 1. CMS Content 2. User information (points, logs etc) 3. Full DB Backup
2. Export the code from the tag into production
3. Move the apache config to point to this new directory (normally using symbolic links)
4. Restart gracefully Apache

Code & Database Release

1. Backup production and staging (3 DB backup files per instance) 1. CMS Content 2. User information (points, logs etc) 3. Full DB Backup
2. Take one node out of the load balancer

In This Page

• Intro & Context
  • SVN Terminology
    • Trunk
    • Branches
    • Tags
• Current Workflow
• Proposed Workflow
  • QA to Staging
  • Staging to Production
    • Code Release Only
    • Code & Database Release

Site Map

Document generated by Confluence on Sep 16, 2014 14:12