Sharing IT Best Practices with youSharing IT Best Practices with you
Producing high quality of the code is one of the basic principles or rules of Agile working. This is also addressed by Lean. Lean uses the principle that a product may not be passed on in the production line if there is an error. The question is how to interpret this in a DevOps approach.
Annotation is the explanation of a piece of source code.
Branching is a technique that makes a copy of the source code to create two versions that are developed separately. After these branches have been altered by the developers, they are reassembled by a merge. There are various forms of branching. Therefore, a DevOps team must make a choice. This choice is also called the branching strategy.
The Definition of Ready (DOR) is a customs toll gate used within Agile Scrum to ensure that the Development team only takes care of those features that meet the requirements of the DOR. The DOR is being owned by the Development team.
The Definition of Done (DOD) is a customs toll gate used within Agile Scrum to ensure that no product in the sprint is accepted by the Product Owner before the DOD test has taken place. The DOD is being owned by the Development team.
A event catalogue is a list of all events of an application including the identification and the category (information, warning or exception).
This is an ITIL® process that defines which events are valuable to recognize and to capture. These may be information events such as starting or stopping a process. It is also possible that there is a probability of an exception. This is called a warning. An example is the 80% full disk. In case the application or infrastructure component does not function properly, there is an exception.
A Standard is an appointment (policy) that must always be met. There are no exceptions. If the Standard is not met then this is a defect. Rules are Standards that may differ under certain conditions. The deviation must be documented and argued. A Guideline is an advise that is not mandatory, but acting on this advise provides a better maintainable product.
Quality Assurance (QA) is the concept of comparing a completed product with Quality Control (QC). However, the QC must be concrete. Therefore, agreements on the quality of work have to be made. SRQ’s are the concrete QC’s which can be applied to toll gates like the DOR and DOD. Together QC and QA (QCA) are the means of getting high quality of code.
One cannot dispute about the taste, it is something personal. This also applies to quality of source code. The quality of the source code can only be measured if a QC is defined. Within DevOps, Agile is used as an Agile Scrum approach. Therein certain quality controls are defined as a DOR and a DOD. However, Agile Scrum does not give content to the QC. The content must be determined by the DevOps team. Nevertheless, there are aspects that are universal and everyone benefits from it. Therefore, this article gives some examples of what possible QC in the form of SRGs.
Some developers claim that when you work in a DevOps team you do not know when development stops. Therefore, if you make the first version of an application, there is a choice whether it should be developed to expand or that a simpler structure can be chosen. Software can easily be expanded when separate classes are defined that later support the software’s modularity. This takes more time than realizing a simple structure.
The question, however, is how much time it takes to restructure later (waste) compared to working on a modular structure from the start. A good solution is to allow for a deviation from modularity because of the time-to-market requirement, provided the product owner has planned on the product backlog a redesign feature that has priority over further development. It is therefore necessary to pay for the deviation in time and money before proceeding. In that case, the product owner no longer determines the priority of that piece of redesign. In this case, modularity is thus one of the Rules.
Another QC is whether branching is used or not. As soon as there is branching, there is waste. After all, a merge has to be performed and it does not produce business value. It is preferable not to make a branch of software unless there is an absolute necessity. Branching is thus one of the Rules that can be deviated, but that deviation must be well-argumented. Some organisations do not work with branches at all.
Within DevOps, the Default applies that any object that is generated is provided with a version and is included in the repository. For source code this is often the case, more and more, that has been the case for decades. Otherwise, for objects that do not contain source code, they are objects that are generated by the DevOps team in a cycle: A database schema, a script to change a firewall setting, an install script, and more. Therefore, in that case, the DoD must be a QC that all changes made to objects that need to be applied to other environments must be signed. The script must contain a version and be included in the same repository as the source code.
Another example of a QC is the quality of the software code such as function names, size of functions, use of libraries, etc. These are source code aspects that are not checked by the compiler. For example, a compiler will not give an error message for a too low degree of annotation. The size of a function is also a choice. A best practice is that one function only takes one A4 of source code lines. The argument is that the function is easy to understand, easy to adjust and easy to test. In addition, check-in can be performed several times a day in order to check that the function works properly.
Many of this code quality that cannot be controlled by a compiler can be recorded by code scanners such as Tiobe. This tool even gives a quality label to the code where ‘A’ is the highest quality and ‘F’ is the lowest. Tiobe therefore indicates which source code rule did not meet the quality aspect. There is also a graphical overview of the overall code quality in pixels (see Figure 1‑1). If a red pixel is visible on the screen, the underlying code line will be made visible while clicking on the pixel. This explanation includes the name of the programmer who wrote the code line and the detected deviation. The quality label can be taken as a Standard and put on the DOD.
Figure 1‑1, TiCS Dashboard.
The advantage of a DevOps team is that both developers and administrators are in the same team. This does not mean developers need no longer worry about event management. In fact, administrators are meant to teach developers how to handle events in an application. There are many SRGs that are related to event management.
An example of a Standard rule is that all events of an application are listed on the event list. The DOD should therefore provide an entry that the event catalogue has been updated for each realized feature. The reason for this being a Standard rule is that the events should be automatically monitored and should preferably be handled automatically as well.
Using DevOps means creating high quality of source code. The usage of SRG’s aid to establish concrete QC’s that can be checked by QA at the toll gates of the DevOps process. Alignment on the SRG’s is very important. Tools can speed-up the QA checks.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Acceptatiecriteria, ISBN: 9789071501784
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.