Code Maintenance

Every IT system has a lifespan. The IT system is continuously changed during the life cycle from cradle to retirement. Changes due to new requirements, anomalies, improvements, etc. 
During the initial implementation phase of the IT system, the DevOps team makes careful decisions about which patterns fit best, which solution is a good match with the business requirements, and lots of other critical choices. The DevOps team is building the IT system with a certain philosophy. 

When the IT system is deployed and used by the users, it moves to the next phase, the maintenance phase. This phase takes approximately 70% of the complete lifespan of the IT system. In this phase, the DevOps team extends the IT system with new features, changes, and fixes problems. 
When the team is extending the IT system, the initial philosophy of the IT system must be kept alive. The carefully chosen patterns should also be followed in the maintenance phase. If the DevOps team deviates from this, the underlying codebase quickly becomes a spaghetti codebase, and the maintainability degrades.

In the ideal situation, the IT system can be seen as a perfect round figure, and every extension only makes the figure bigger. When in the maintenance phase, sub-optimal decisions are made, the figure will become an odd figure.

The last phase in the life cycle of an IT system is the retirement phase. This phase starts the transition to a new system, or the system is not replaced because it is obsolete due to technical or functional reasons. 

In the chapter about Test Automation we state that test code should be treated the same as production code. To keep the philosophy and patterns in the production code, developers follow architectural principles like:

• Single-responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion (SOLID); SOLID is used to make production code understandable, flexible and maintainable
• You Ain’t Gonna Need It (YAGNI); Keep your codebase clean, and don’t develop code that isn’t needed. Remove code if it isn’t used anymore.
• Keep It Simple, Stupid (KISS); Don’t over-engineer the code base of the IT system. Simple code is easier to maintain and understand.

New features, changes, and problem fixes in production code are applied in so-called feature branches. Feature branches are code lines derived from the main code line. 
When the code changes are applied, the related test code should be changed, or new test code should be developed especially for the specific change (feature). 
When the change in the production code is approved, the code base, including the test script code, is merged into the main code line. To make this a successful automated process, everything must be built as mergeable code. 
If the code is not automatically mergeable, merging the code into the main code base will be more labor-intensive and error-prone.