Why is the development of a REST-API Webserver Application with less expected changes after its short term initial build a DevOps project?

Question

I am thinking about setting up a project where a one-year development / built phase of a rest-API Server is planned. Providing an initial version in three months and deploying updates every month during the first year should be enough.

Further information to consider:

• After the services are built, they should be relatively stable for a long time. It is not expected to change the code every week. Probably one time in three months.
• There are only 10 people affected if the API does not work. And there will be no major business impact from being down.
• Code is not affected as a whole. Changes in one web service API will not affect others.

To set up a DevOps structure in order to ship updates fast and continuously is questionable since it takes some effort to set it up with no real benefit. Since there are not many changes expected during the lifecycle, there is no real benefit of DevOps.

Is this view right? what else should I consider?

A friend recommended me to use DevOps procedures anyway. Does this makes any sense?

Answer 1

DevOps isn't just linked to frequent high-quality deployments, it is also linked to many other outcomes. The capability model for DevOps that is published by DORA allows you to adopt the techniques and practices that are relevant to your context. You don't need to tick every box in the model.

The 2022 State of DevOps report used clustering to identify different performance levels that aligned to different product development stages.

If you aren't going to be making frequent changes to the software:

• Starting (making sense of the problem by experimenting to a solution)
• Flowing (active development of a competitive software product)
• Slowing (less frequent changes, customers like the product)
• Retiring (planning to retire software)

It sounds like the goals of your API align to that "slowing" state, where you don't deploy often but can keep a reasonable level of reliability.

You would apply "just enough DevOps" to make your life easier. For example, it may be tempting to do manual deployments because you won't do them often, but automating this will mean they work (if you don't deploy often, you forget the manual steps and make mistakes).

So, yes - I'd still "do DevOps" - though not every single capability in the big diagram. Applying Continuous Delivery is a good starting point for your use case.