Team dynamics and work flows
I'm writing this article pasting our internal guide with some of our own dynamics, that i wrote time ago.
The idea is to share what worked for us, so you can take it as an ideas, or things to have in mind.
PS: Titles meant to be funny (sorry i failed as a comedian).
Overview
This doc is meant to describe the dynamics, flows, and philosophies that Outside The Cube Team has.
Specially wrote for internal use as a guide.
Tools & Dynamics
Git flow or leave
As part of our work dynamics, we use git flow to standarize the commit and merge flows.
The idea is to:
- manage every task as a feature
- make code reviews of features (align with other point of the guide)
- after approval merge feature into develop
- when is needed release a version to master with semVer version tag
SemVer or not version at all
For versioning we use SemVer definitions that allow us to manage the different types of versions with patch/minor/major.
This way we can have distinction between new version with fixes, with new functionalities but with total compatibility, or changes not fully compatible.
The version tag will be like: major.minor.patch
example: 1.0.0
TDD or die
We use TDD (Test Driven Development) as our software development methodology.
The idea is to define first what we need to test, make the tests and then start coding.
This way we won't adapt tests to match code, the idea is to make code that match tests.
The idea is that every project has:
- unit tests
- integration tests
As a complementary thing totally optional the projects can have automated tests.
Dockerize the world
All the projects needs to be dockerize and running on ECS, with docker-compose for local testing.
The only projects that will be an exception for now are the ones very complex to dockerize and to work with env variables.
For now the only ones out of scope will be:
- old versions being migrated
- chat server (tigase)
Code reviews for everyone
Every feature needs to go thru the code review flow.
The idea is that every feature achieve two approved marks, only then can be merge to develop.
The only exceptions will be:
- Define the feature as an exception due to timelines
- Due to language/technology, cannot achieve two approved so with one will be enough
Jenkins to deploy
All the projects needs to be able to deploy by jenkins, even the ones not dockerize.
For now the only exception will be the ones being migrated or yet to come.
Philosophy
Cannot be tested? then cannot be deployed
We need to make sure that every project can be tested fully, and is aligned with the TDD methodology.
The idea is that every project can be tested locally with unit tests and integration tests.
If there is something that cannot be tested automatically, then needs to be possible to test it manually as a complement of the other tests.
Has code? needs to have a document
The idea is that every development project has at least one document describing it.
The goal will be to have:
- architecture doc
- description/specification doc
- implementation doc
Depending on the project can be more or less document, but this is the general idea.
Run it locally first
As part of TDD methodology, and the first philosophy point before deploying to dev we need to be able to test things locally.
Also define by the other points needs to be able to:
- run unit tests/integration test locally
- run and test manually
Complex to deploy? needs to think more about it
The idea is that every deploy flow is as easy as can be.
For this all the projects needs to be deploy by jenkins, even the ones not dockerize.
If there are too much manual steps then we need to think more and simplify as much as we can.
For now we will have:
- Dockerize projects running on ECS: will be deploy by jenkins, and env variables manage by IT (with terraform)
- Not dockerize projects: in this case tigase will be deploy by jenkins (not yet), but for changing set up we will need to log in ssh to the specific node.