Proposed development/deployment workflow

Prerequisites

• Each microservice has a version (either in the package.json or somewhere else)

Proposed workflow

• Developer creates a branch, forked from master

• Developer makes the changes

• Developer tests the changes on the local machine

• Developer makes the PR

• CI checks pass

• Developer bumps the version and merges into master

• The docker container with the tag of the latest microservice version and latest is built and pushed to Dockerhub by CI

• Developer deploys the changes to staging (either through some automated tool or by doinggit pull origin master on the microservice repo and then make start on the staging) and tests stuff there

• Developer deploys the changes to production (the same way) and tests stuff there

• Everything is awesome, the task is closed.

What if something will go wrong?

If something that is on master appears to be wrong on staging, the workflow is the following:

• developer creates the new hotfix by creating the branch forked from master

• then the workflow is the same as for usual development/deployment.

What is something is wrong on production?

If something that is on master and is already deployed to production is broken and it’s only found out on production stage, the workflow is the following:

• developer rolls back the production release (probably by manually editing the docker-compose.yml of the service and setting the version as fixed

• then the workflow is the same as for the usual development. When stuff is deployed to prod, the container version should be automatically latest and everything should work as expected.

Do we need stable container tags?

I think we don’t need it for the following reasons:

• everything on master is already stable. If not, the developer will find out about that on staging. (Or on production, but the chances are pretty low).

• we won’t need to have some complicated workflow on choosing what is stable and what isn’t

Decreasing the errors possibilities

What we can do to decrease the probability that something broken will be deployed on production and we’ll find out about it from angry AEGEE members? Obviously it’s testing!

• testing stuff on staging before deploying to production

• have backend tests - pretty much done, we have it in every repo (core, mailer, events, statutory, discounts)

• have integration tests - run the whole setup and do browser actions (so we’ll know if something’s broken in frontend/backend interaction or in the frontend itself) - to be done, need to discuss and implement it.

Point is, we should have everything covered as much as possible so such errors won’t have the chance to make it to master.