In 1st Part of Basics of DevOps, we discussed the basics including definition and origin of the terminology. In 2nd Part of Basics of DevOps; misconceptions, principles, requirements, benefits were discussed. In 3rd Part of Basics of DevOps, We Discussed About DevOps Team Covering Team Structure, Project Management, Design and Quality Management. In 4th Part of Basics of DevOps, We Will Discuss About DevOps Processes Covering Processes, Design, Design, Development and Testing.
4th Part of Basics of DevOps : DevOps Processes
In a company, there is a large variety of processes and processes that are defined and documented in the companies. Each company has its own definitions and these are all recorded in different documents or on platforms. The term “DevOps” has not been known for a long time in companies and therefore there are no standards or guidelines that are used in companies. It should also be noted that the term allows a wide range of interpretations. The viewpoint plays a special role in the consideration of the processes, also the task in the team plays an important role.
Essentially, DevOps seeks to bring together the processes of operation and development or to harmonize them. The processes of operation, development, build, testing, deployment, execution are defined as main processes in DevOps. Also it tackles development, UX (as a business), testing and service in their work as processes.
Design and Design Process
---
The design and design process involves a kind of processing of the requirements of the operational side of DevOps. In the agile environment, special teams have been developed that are able to work in a particularly high-quality manner and can react to customer changes as quickly as possible. These specification requirements are then extracted into initial designs and agreed with the customer. Due to the agile value system, these votes are made continuously. In addition to the collection of requirements on designs and specifications, the release planning is discussed. This includes the planning of deliveries at certain intervals (continuous delivery), the documentation of dependencies among the individual releases and a provision for errors within the delivery. Furthermore, in the Inception phase, it is checked whether further training or training for the employees has to be arranged for the use of the software. If out-of-test deliveries fail, then contingency plans/processes must be defined to intervene in this emergency.
Development and Testing
Due to the large proportions of the respective processes within the respective areas, the processes are initially considered separately from each other and finally merged into one process. Due to the non-existing or defined processes, the following processes address the generally applicable procedures, which are however used within DevOps.
Development
For development, it is important that all developers work together on one foundation. As a basis for this, there are various approaches or systems that support one’s own processes for joint development (English: Collaborative Development). In the past, developers had developed the source code locally, which changed in the 1980s when the CVS (Concurrent Versions System) was introduced and in the 2000s the SVN (Subversion).
CVS and SVN were centralized solutions where developers could check out the source code to process it locally and then send it back to the server.
The most recent solution for the centralized development approach is based on GIT’s. This provides that the developer copies the relevant source code from the central solution as a clone to the local system. From this clone, the developer leads so-called “Branches” in which he can make changes to the source code and locally test whether they meet the requirements. It is possible to create several branches to develop independent solutions or fixes for the “Master Branch”. To communicate with the Master Branch there is GIT-Bash.
During the process of development, individual changes made locally within a branch are tagged with specific versions that allow developers to accurately verify which source code was transferred from which developer to the master branch at what time. The versioning receives a so-called “commit”, this commit refers to the changes and describe them in a short sentence in order to enable a common understanding across people.
Tests : Automation in Development
Due to the fact that DevOps uses many automatons, the testing is also automated. Here, however, there is still no clear assignment who takes over the test automation within the project, it depends on the existing staff and the respective knowledge of the tool used and the programming language used.
Many rely on a cooperation of development and operation and picks up on the automation pyramid as the basis of the tests. This states that the unit tests are first written in the process, followed by the service tests and the UI tests. The process of testing is also carried out in development. The process is carried out when there are no employees with development skills in quality management.
Unit Tests
Unit tests are independent test cases that have no further dependencies. There are specified tasks tested, which are processed accordingly in sets. The method is also called white-box testing, because knowledge about the written source code must be present for the tests. Test cases are written by quality assurance before being implemented by the development department. This requires close cooperation between development and quality assurance.
Service Tests
In the course of the service tests the integration of the interfaces within a software is tested. The developer checks whether the written source code communicates with the other interfaces and can exchange information. The method is white box testing due to the knowledge of the source code and is seen as a second process step.
UI Tests
UI tests, so-called black box tests, since they do not know the written source code and test the functions of the finished software. These tests are also called functional tests and are defined by quality management. The development then implements these test cases in the automation and checks whether the expected result occurs.
Testing
In accordance with the current recognized guidelines of the ISTQB (International Software Testing Qualifications Board), essentially the processes are applied in quality management. These are also related to the DevOps environment as it comes from the agile environment. This test process serves to structure quality management and as a general basis for quality assurance.
Test Planning and Test Control
In the course of the test planning, the resources intended for testing are managed. The most important document during the test planning is the test concept, which is created during the planning. Within the test concept, the test strategy is defined, which is based on the risk assessment of the individual software components. Furthermore, the individual tests are subjected to a first prioritization and tested in how far this is meaningful. The test control is used throughout the test process and is based on the metrics collected through the execution of the tests.
Test Analysis and Test Specification
The test analysis starts in the process with the analysis of the test basis, the test basis is the basis of all existing documents, which are meaningful for the development of the software. Furthermore, the testability of individual modules is checked and the previous risk analysis is consulted again. Within the test specification, first logical test cases are created and in a second step concrete test cases. Care must be taken to ensure traceability between the requirements and the specified test cases.
Test Realization and Test Execution
During the test realization special attention should be paid to the logging, as tests without logging are worthless. However, before proceeding, the test environment, the test data and the completeness of the parts to be tested must first be checked. First the test cases with the highest priority and then descending by priority are tested. In the event of deviations from the expected test result, these should be documented as mentioned above and retested after development has been corrected.
Test Evaluation and Report
In the process of the test evaluation, the criteria defined at the beginning, which determine the termination of the test execution, are compared with the status. A concrete end of the testing is defined by the time and the costs. The report compares the costs with the costs and how far they are justified.
Completion of the Test Activity
The focus of the completion of the test activities is the experience gained during the test. These are prepared and analyzed in order to be able to use them for later projects. Furthermore, all test media are archived and the documents are completed.
Merging Development and Testing
Development and testing run parallel to each other during the entire project and are in constant communication with each other. The respective processes with the sub-processes are coordinated within the project and treated differently in each company. Since there is no basic concept for DevOps, the companies and project teams are free to choose the processes and processes.
Deployment and Support
Deployment
The distribution process refers to the distribution of the versions to various systems and environments. This process, is an “all or nothing” process. Upon delivery, a system either continues to run normally or is no longer operational. This can lead to high losses.
The process in the course of DevOps also becomes “Continuous Delivery” and, in addition to the delivery to the customer, also includes the delivery of different versions to the development and test systems. The required data and software components are automatically merged via a tool, creating a new version that quality management can use to perform manual tests. As an important part of the deployment is the pre-defined release plan, which must be observed during the entire development phase. Before a stand can be delivered, it first goes through several stations.
Deployment Stations
This process involves the delivery of two versions. These are based on two states: an already tested and approved system (stable) and a version that contains current bug fixes or new implementations according to requirements. The stable version is shipped to a certain number of systems and the version with bug fixes or innovations is shipped to a certain number of systems. It then checks whether the system with the bug fixes and innovations also works completely in the customer’s environment.
Rolling Upgrade
In the process of the Rolling Upgrade process, a version with fixes and fixes for a stable version is immediately exchanged on the system. It will be replaced at certain intervals, the other existing versions and in short iterations the other. This process is particularly cost intensive and expensive and requires a higher number of systems.
Support
So-called support describes the continuous support of the systems on which the releases are tested and developed. After a first delivery, the following versions are supported with the methods and processes described above.
Monitoring and optimization
The goals to be pursued are the following:
- Ensuring errors and their causes, even if the error has already occurred
- To identify and document speed issues on the system, software, or the interaction of software and systems
- Presentation of workload and resource usage on the platforms and planning for later developments
- Behavior of the user should be identified and logged in order to develop more targeted and to be able to place operational aspects such as marketing better
- Monitoring and detection of possible attackers on the system
In order to be able to carry out monitoring, the developers must have already incorporated it during the development phase. This refers to the so-called creation of log files. These contain information about all actions and reactions of the software in a certain period of time. After the development has implemented them in the software, selected tools for the respective areas can be set up. Each team has its own software to access the required information from the system or the customer. The development follows the technical goals listed above for use in later optimizations. Based on the data collected, the developers can, after analyzing the data, react specifically to weaknesses in the system and the architecture and consider these as a result of further developments. For the operationally oriented teams within a project, so-called “boards” are created to represent key figures for the behavior of the customer based on metrics and diagrams. Previously, the data are also analyzed by the operational teams and can then be forwarded to the management after the aforementioned processing.
Conclusion of Part 4 of Basics of DevOps
In the previous articles and the current, we learned the fundamental goal of the DevOps movement is to bridge the gap between development and operations. Processes should be executed together. But in terms of the tools used, there is a clear gap between development and operation in traditional IT operations. So the goal must be to close this gap and find a set of tools that both working groups can accept and use. In the next part of this series, we have ended this series of discuss with platforms and tools for DevOps.
