56 lines
2.6 KiB
Org Mode
56 lines
2.6 KiB
Org Mode
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:
|
|
|
|
- Code Reviews
|
|
- Acceptance Testing (including UI and business tests)
|
|
- Automated System testing (to be developed)
|
|
- A mini-qa, focused on the feature, by someone not directly involved
|
|
in its implementation
|
|
- If possible, deployment to a beta customer.
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|