Home

product workflow

for the most part, we'll follow git flow.

Feature development

1. clone the gamify repo to your localhost
2. assign yourself to an issue. move the tile to the "In progress" section in the projects tab. Make sure the issue is part of the current milestone.
3. create a new branch. it should be called feature/<number> where the number is the number of the issue being worked on. For now, feature branches will not be shared
4. do your dev. run unit tests locally with go test
5. When the feature is ready, before opening a PR, rebase your branch on the latest develop code: git pull --rebase origin develop. Resolve conflicts if necessary, then push the branch.
6. Open a PR from your feature branch to the develop branch. This should trigger CI. You should see the status on the PR itself. feature branches should only be merged into develop.
7. CI must pass to allow the PR to be merged.
8. The person merging the PR should also delete the feature branch. This option is offered directly in the UI on github.
9. repeat from step 2

Release workflow

1. once all changes for a milestone are merged and tested in develop branch. create a new release branch from develop. The branch should be called release/<milestone name>. one milestone = one minor release.
2. open a PR from release branch to master, as well as release to develop. In the meantime, development can continue on the develop branch.
3. if there are bugs in the release, they should be fixed on the release branch.
4. If tests pass, merge code into master and back into develop
5. let master run its final testing and packaging after merge. If it is successful, master should be tagged with a new version. Follow www.semver.org rules. our first usable 'release' should be v0.1.0
6. if bugs are found in release testing, open a hotfix branch, merge into release and develop, and re-test

bugfix workflow

If a bug is found in develop or release, it should be fixed in its own branch and merged back with the parent branch, similar to a feature branch with a more limited scope.

1. create a new bugfix branch from develop/release: bugfix/<issue number>. name should ideally include the number of the open issue in the repository.
2. fix the bug
3. open a PR to develop/release. PR into a release branch should run unit/integration tests
4. merge into develop/release, re-run tests, etc

Hotfix workflow

If a bug is found in master, and we decide it needs to be fixed quickly outside of the normal release scope, we should follow the hotfix workflow.

1. create a new hotfix branch from master: hotfix/<issue number>. Ideally the branch should be named after an open issue on the repository.
2. fix the bug
3. open a PR back to master
4. open a PR back to develop
5. update the master release tag. increment the 'patch' version number.

Testing workflow

1. every go file should have its own set of unit tests. developers are responsible for keeping this up to date. Ideally each PR should contain at least one unit test that verifies the changes made. We should use a code coverage tool and try to keep coverage above a certain percent. This can be bypassed early on while we get some basic project structure set up.
2. vue probably has some ways to test as well. need to investigate this.
3. when a PR is opened from feature to develop, run all unit and integration tests, along with any other checks
4. when a PR is merged into develop, artifacts will be built. there should be a develop environment that is constantly deploying the latest develop artifacts to the kube cluster.
5. when a release branch is created, it should be automatically deployed to a temporary release environment to be live tested (QA style). It will expose DNS and behave exactly like the full production site.
6. further commits to release (via bugfix) are re-deployed automatically to release environment where they can be tested again.
7. once release is merged into master, master will be auto-deployed with the release artifacts. further testing or feature spot-checks can occur on prod if necessary.
8. when release branch is deleted, the release environment will be automatically deleted, including the namespace. no trace should remain.

CI/CD and Automation

1. devs will run unit test locally before pushing.
2. every PR to develop will run CI (unit/integration) with status reported to github. PRs cannot be merged until status is green. Other checks might be made as well (gofmt, godocs, code coverage). All checks must pass. Build results will be reported via slack and/or email.
3. PRs merged into develop will trigger a docker build process, followed by deployment to the develop kube environment
4. once tests are validated in that environment, a manual release branch is created.
5. creation of a release branch rebuilds the (hopefully) final version of the application artifacts, and deploys them to an auto-generated release namespace.
6. once release is verified, release branch is merged into master. this should cause master to be automatically tagged with the next minor release. This should then re-tag and push all of the release artifacts with the new release version
7. after release branch is merged, it can be deleted. This should trigger a workflow that automatically deletes the release deployment, service, and namespace. perhaps the merge itself can trigger this?

Infrastructure

How I envision the infrastructure.

• kubernetes
• use terraform for all configuration. it can provision the cluster as well as the kube objects themselves.
• use GKE with cluster autoscaling set to a minimum of 0 nodes.
• create a develop namespace, and a production namespace. They will be in the same kube cluster
• develop does not use pod autoscaling, but uses 2 replicas by default.
• release will set pod autoscaling with a relatively low max (5) so that scaling can be tested. Scaling should be based on memory usage
• production will set pod autoscaling to a slightly higher max (20). also based on memory usage. In combination with node pool scaling, this should allow the application to take on considerable load automatically, while having relatively low cost when load is low.
• develop and production will each always have at least 1 load balancer. possibly 2 if API splits from UI later. release will have its own for the short time while it is being tested. This will incur additional cost.

Infra Costs

General summary of what we will need from GCP and approximately how much it will cost.

item	cpm	quant	total
small vm	5.00	2	10
ext rules	5.00	2	10