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.

Hero Icon

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.

Blue background

Get in touch

Book a free consultation meeting with us

Lets discuss your idea