Automation
We all are engineers. Maybe not all of us have an engineering degree, but we are all engineers. Engineers build engines. Our engines are intangible, yet they are controlled by the same laws of cybernetics.
These moving engines work well for our customers.
Maybe, you never thought about that. But just like a car engine is "a system", so is the whole factory that makes things like engines. These systems might be as exciting as the engines they make.
Things making things. Things enabling things. All of those are things that have the purpose of improving productivity, quality, and predictability. They can help new people to get productive faster.
Installation should be easy
It should be easy to download the app and install it. In the ideal world, just one or a few commands.
Also, for a developer, it should be easy to clone the project and get the development version running. Again, 1-2 commands to install dependencies, and 1-2 config files with reasonable defaults and documentation. And a few commands to run dev, run, compile, lint.
Upgrade should be easy
Migration from an older version to a newer version should be ideally just 1 command.
Pulling new changes and upgrading the app shouldn't be any more difficult.
Tests are running everywhere
There will be tests. It should be easy to run them.
These tests should run on dev machines, and dev environments and this should happen often.
Tests should be fast if possible. E2E tests might be always slow, so it is good practice to be able to run all tests except these.
We have development, pre-prod, and production environments
Each project is running on developers' machines. If there is a dev branch, it is running somewhere for the PO to see.
Work in progress is merged into the master. At every moment after v1.0, a commit in the master is considered stable and running somewhere. And newest commit in master is running on a pre-prod environment.
By having this, PO and others can always see:
- What is the latest development version?
- What is the latest version good enough to be merged to master (that has been probably confirmed by PO)
- Production version
Post v1.0, we release often
Once the team achieves version 1.0, the team should release often. Releasing should be automated. Rolling back releases should be automated too.
The app has backups; backups can be recovered
The team or infrastructure team must have backups in place the day the application is released. Since that, backups must be maintained and from time to time, recovery must be tried.
Join Our Webinar!
Automatic Backend with PostgREST. Xiana + PostgREST shared JWT token
Discover how PostgREST automates backend tasks by effortlessly generating a REST API from your PostgreSQL database, saving valuable time and resources.
22
May
06:00 PM
CET