Production Ready: how to check product performance

What does it mean when we say "the product is ready?” Each developer has their own answer to this question. Though views may coincide, interpretations will still vary and, sooner or later, any team will need to develop a common language that would allowing a product to be seen from the same point of view and produce stable result produced. These unified views make up the concept of Production Ready.

The general criteria for the Production of Ready help the whole team

• When the team agrees on requirements the product must meet, it becomes easier for developers to work.
• If everyone puts the same meaning behind the concept of readiness, results won’t vary depending on which developer is doing the work: there will be no cases when someone did not do any, say, logging, because they somehow thought it was not necessary.
• The project manager has fewer headaches, as he knows what condition he will receive the product in and what the customer can be guaranteed.

Our set of Production Ready criteria combine both our own knowledge and best practices from the "outside world" of development. Now, something here should be emphasized: you don't have to copy someone else's experience, your team can have their own style of work. The only important thing is that it should be effective and meet the common standard you have adopted.

So, how do we understand that our product is really Production Ready?

1. It meets the project requirements. Primarily, this point assumes that such requirements exist, and are formalized and documented. This includes the client's requests, user requests, and the technical requirements of the environments. All team members know about these requirements and are guided by them during development.
2. The product architecture is well-designed. Meaning it is not formed spontaneously. If the solution is pre-designed, its architecture takes into account possible risks and development prospects. This approach will allow the team to think through the fault tolerance of the product, determine in advance the technical means that will provide the necessary functionality, and check compatibility. Otherwise, it may turn out in the future that it is impossible to implement the necessary feature without reworking the fundamental modules of the product. Other criteria depend on the architecture – something we will return to later.
3. The system can be tested. In this case, we do not mean 100% test coverage (although this is also a good thing). It is important to build in the opportunity to evaluate system performance before it is launched into battle. It is not so important whether these are manual checks or automated tests – the main thing is that the product itself can receive test data and produce a result. At a low level this means, for example, that there are no strongly connected classes in the solution, and that each module can be checked using abstractions and mockups. At the top level, it means you have a test environment, and health checks will not cause problems for real users.
4. The product works stably. There are no systems that run smoothly 100% of the time, so stability should be understood as compliance with SLA requirements. These requirements vary from product to product, and sometimes even from one system module to another. A business card site and an accounting system have fundamentally different requirements for stability. The most important thing is that they are registered in the SLA, and the team guarantees their implementation.
5. The solution is ready for support. The team has logs and monitoring tools, and developers can quickly determine what is broken and how to fix it. Plus, the product must be repairable, i.e. you can diagnose and fix the error without rewriting the entire application. Sometimes it is impossible to solve a problem due to errors at the architectural level; for example, if the developers chose a bus-line that cannot cope with the flow of requests, and you wind up having to change the entire system.
6. The system can be scaled. Another thing that is built within the architecture. It is pertinent to remember that you can economize on resources, but not on technology. For example, at launch the product is supposed to cope with a thousand requests per hour, and in a year the number of users grows, with the load has reaching ten thousand: The team must have an idea of the product life-cycle in advance, understand what technologies will be required at each stage, and how to ensure their performance.
7. The product is documented. Once again we are talking about the possibility of preparing documentation itself. In a broad sense, the product should be documented automatically – descriptions of interactions, infrastructure, etc. should all be contained directly in the code.
8. The product works. This may seem obvious, but one needs to realize that as long as the solution is not running on a "battle" server and real users are not working with it, the system cannot be considered ready. If a code that fulfills all the requirements lies in Gitlab, but is not running on the server, the product is not ready.
9. The product has value. This is the most extensive topic on which we could well write a separate article, if not a book. Without going into details, we will put it this way: the system solves the business task assigned to it - sells tickets or insurance, provides mutual settlements with customers, helps employees to arrange vacations, etc.

To summarize

The same Production Ready criteria will help you achieve the same result, regardless of who creates the product or manages each specific project. Determining what Production Ready means will be useful for anyone who wants to build simple, clear and logical development rules for their team and product ecosystem.