We are going to experiment with our development process, getting away from cycles and towards more continuous development. The main idea is to get rid of the prod and QA branches and instead deploy directly from master, which we keep deployment ready at all times. Development occurs on private branches, each branch mapped to a separately deploy-able project. Each of projects will be managed more or less independently and will include specification, development and validation stages. At any particular time we might have anywhere from 1 to 6 projects in flight each of which continuously pulls from master, but does not push back to master until the code is ready to be deployed to production. The point at which a project is ready to be deployed then takes roughly the place of the QA phase of our old cycle mode. At this time, we will do a PR, and go through a series of validation steps, to make sure the work meets our standards. This validation includes:

Once these QA gates are passed, we will update the release notes, tag a new version, integrate to master and then ideally immediately deploy to a customer.

The main goal with this change is to reduce the latency from feature specification to production roll out. We also hope to improve throughput by making more efficient use of QA time and reducing idle cycles. We expect people to participate in more than one project depending on their area of expertise and work load. This does not mean people will work on two things at the same time, rather that people come into and leave projects as they free up and not when the project starts or ends.

This new scheme will come into full effect when we finish 1.3 although to some degree 1.3 was already setup like this. At the moment, we have 3 major projects, vap/settlments/implied, grid settings and speed work, which are in branches of prod. We will merge these back to prod and then master this week. We have 3 other projects that are in master, the excel API, the server side SDK and the MIC administration and enforcement components. These we hope to stabilize as soon as possible so that we can merge them to prod and deploy them along with the rest. Once we have all this, prod and master should be identical and we will delete prod and operate exclusively out of master. Please avoid committing anything new to master so we can complete this transition as soon as possible.

Let me know if you have any question

Author: ppinto

Created: 2018-10-08 Mon 18:50

Validate