Quality is an accumulation of subsequent right decisions.
- Local development must be super easy to do.
- Linting must be a standard.
- Testing must be very easy to do and run.
- The CI must run on any push.
- Deployment to staging must be cheap.
I have seen local developer setups that were so complicated, that it took days to get set up.
Especially when other services are involved, things can get messy. And then you need to run dev environment, but also the tests.
Also important: Have a comprehensive README.
What helps us:
docker compose is great. And then having a good readme to walk through the steps.
We just follow the “Standard” gem for ruby. Many other programming languages have linting.
Bonus of using Python: the syntax is very straightforward.
Problem with something like Ruby or PHP: It can have many styles.
erblint to make sure the code always looks the same.
Local testing is super important, because then developers can apply TDD.
simplecov - it makes is mandatory that there is enough test coverage.
Usually CIs run on every push to a branch / PR / MR. That’s a good way to go.
A company I worked for even had a kubernetes setup that created playgrounds for every feature branch. That’s too much for a small company, and has different drawbacks.
Best way is to create previews of the software (usually staging / preview env) on demand. Then a version can be tested before it is released to production.
In order to test a version, we need to test it on a preview/staging environment.
These things have helped us a lot:
- Versioning in the footer, and a “Deployed 10 minutes ago” information
- The same code as runs on production, so the same things can get tested
- Deployment from a “preview” branch. Devs can use it anytime
Production is then deployed from the main branch with a version tag.