CloudServices/Loop/Deploy

The Loop service is the server-side component of the Loop project.

It's composed of two parts: - loop-server, the Node.js service at https://github.com/mozilla/loop-server - loop-client, the "client" part composed of static files, served by our server

Both parts are currently deployed and served by the same instance servers.

See : https://wiki.mozilla.org/Loop

Contacts

• Dev Team
  • loop-server
    • Tarek Ziadé <tarek@mozilla.com>
    • Alexis Metaireau <alexis@mozilla.com>
    • Rémy Hubscher <natim@mozilla.com>
  • loop-client (main devs)
    • Mark Banner <mbanner@mozilla.com>
    • Dan Mosedale <dmose@mozilla.com>
• OPS
  • Benson Wong <mostlygeek@mozilla.com>
  • Bob Michelleto <bobm@mozilla.com>
• QA
  • James Bonacci <jbonacci@mozilla.com>

Deployment

There are three deployed environments. A fourth will be deployed later.

Dev

• Host: https://loop-dev.stage.mozaws.net/
• Maintainer: DEVs
• Tokbox mocked? NO.
• Usage: Development and integration
• Updates:
  • loop-client is updated automatically every hour and should match the latest master of the repository
  • loop-server is updated with the master branch by devs on a regular basis - or upon request. you can get the version by displaying the root URL of the server.

This environment can be used to test end-to-end scenario until the service hits the Stable channel.

Load-Stage

• Host: https://loop.stage.mozaws.net/
• Maintainer: OPS
• Tokbox mocked? Yes (but can change, check the / endpoint for more info)
• Usage: Server-side QA and Loadtesting

This environment is used by QA and dev for load tests. The goal is to measure how many connections can be handled by the server and anticipate errors that might happen on high load.

tokbox created keys are not real ones, they are collected by a fake mock server. We deployed it at http://loop-delayed.dev.mozaws.net/

Real-Stage

• Host: To be defined
• Maintainer: OPS
• Mocked tokbox?: No
• Usage: Client-side QA

Not yet commissioned. This environment will be used for end-to-end testing of the service once it hits the stable channel.

This server will be a perfect mirror of the production environment, updated with the tag of the upcoming release

Production

• Host: https://msisdn.services.mozilla.com/
• Maintainer: OPS
• Fake tokbox?: Of course not :)
• Usage: Production apps

This environment is used for production and is the default server for Nightly.

The prod environment provide a Mobile number validation for the following countries:

Releasing loop-server

Ops procedure

Releasing loop-client

The loop-client repository is a mirror of the necessary parts from mozilla-central. It is automatically updated via a script in the repository, every hour (if necessary).

Release process:

• Check loop-client has all the required changes
• Update the Changelog.txt file
• Checkout a fresh loop-client repo, make sure the directory name is `loop-client`, then

cd loop-client

# Replace '0.4.0 with the correct version
./create_release.sh 0.4.0

• The new release tag will be automatically pushed.
• Visit the loop-client releases page, then:
  • Select the newly created release
  • Select `Edit Release`
  • In a file explorer, navigate to the directory above loop-client.
  • Drag the `loop-client-<version>.tar.gz` and `loop-client-<version>.zip` files to the files box on the releases page.
  • Save the new release
• File bugs for pushes to:
  • staging
  • production.

Further info: https://etherpad.mozilla.org/loop-client-release

Release Cycle

The service is continuously pushed into the dev server where client developers can test it.

The service is released in load-stage then production every other week (or asap if we discover a security breach)

• Tuesday - end of previous cycle. tagging. pushed to load-stage
• Tuesday through Friday - load testing by James on load-stage
• Monday - push to production if no regression, if any regression backed off

The Tuesday release will be announced to the loop mailing list when the tagging is happening, so everyone has a chance to try it out.

Theorical dates for July/August:

• July 8th - tagging
• July 14th - prod push
• July 22th - tagging
• July 28th - prod push
• August 5th - tagging
• August 11th - prod push
• August 19th - tagging
• August 25th - prod push
• and so forth...

Once the service will hit the Stable channel, we will introduce the new real-stage environment

Branches and bugfix deployments

In case of a bugfix:

• A commit will with the fix will be pushed to master.
• A new branch will be created on the github repository with the versions that needs the patch, and the fixes will be applied there (backported).
• A new tag will be created with the new version (the patch version will be updated) and a deployment request will be filled.

For instance, in case the 0.9.0 release contains a bug that needs to be fixed:

1. Fix the code in master;
2. Backport (cherrypick) the commit in the 0.9.x branch (create it if needed);
3. Tag a new minor release: 0.9.1 and fill a new deployment request.