In one of the projects, we faced the non-trivial task of describing modern software development as a kind of technological platform. What must be included in it, what tasks should be solved? Not limited to the standard eight DevOps, we have compiled a fairly detailed functionality matrix, trying to describe everything in general. Then we want to decompose the software used on it and put things in order. Look, have we forgotten anything?

Modern software development in our understanding is a well-established DevSecOps with a maximum of automation, which relies on cloud infrastructure. We believe that the infrastructure, including containerization, exists and is ready for any of our wishes. But what is above?

You’ve all seen the standard DevOps eight, here it is.

But if you take these 8 stages, find suitable software for each and try to start the development process, nothing will work. After a little thought, we realized what needs to be added. Two more sets of processes are “Management and Communications” and “Process Monitoring”, which are outside the eight and are associated with all DevOps engineering tools.

Well, now let’s try to parse each element to separate processes.

Management and communications

1.1. Project management

In the software development process, it is necessary to control the process as a whole, go towards the intended goals, and coordinate the efforts of several development groups and related departments. Plan and track progress.

1.2. IT resource management

Development requires quite a lot of resources in addition to the actual programmers, analysts and testers. Computing power, disk space, licenses – all this must be managed so as not to interfere with the main process.

1.3. Requirements Management

Software requirements live their own lives: old ones become irrelevant, new ones appear, those that seemed unshakable change. Moreover, quite often the number of requirements at the final stages of the project differs several times from what is written in the TOR. All this must be monitored.

1.4. Task and backlog management

The tasks facing the project are decomposed into tasks for the development of specific modules, plus new ones appear in the course of work. All this must be stored somewhere, distributed among the performers and tracked for execution.

1.5. Release Management

Releasing a release is not only an automatic action within a DevOps tool, but a full-fledged process of planning and coordinating the actions of all teams involved in development.

1.6. collaboration

In the process of development, the participants have to interact in any way: work together on plans, give their assessments, create reports, and confer on controversial issues. It is desirable that all this happens in a controlled mode with convenient tools and fixing the results.

1.7. Process Artifact Management

Any activity generates a bunch of artifacts: documents, graphs, libraries, prototypes, etc. They need order in their storage and classification in order to be able to quickly find something and, for example, reuse it.

1.8. Delivery Management (Release Automation)

It would seem that delivery is part of release management, but no. There is a lot of managerial work involved in coordinating delivery, which is best thought of as a separate functionality.

1.9. R&D process management

The development platform should not be static, you need to do something like research all the time, what new technologies, practices, tools can be included in it.

1.10 Management of maintenance processes

After the release, we need to collect feedback, monitor the parameters of the applications, so that there is something to form new requirements from.

1.11. Knowledge Management

This point is not even worth commenting on. In the development process, you need to collect not only artifacts, but also knowledge in order to quickly bring new employees up to date and provide valuable information to existing ones.

1.12. Managing CMDB Configurations

This is already a borderline functionality that allows you to have quick access to the current configurations used in the development of software and hardware.

What was not included in the set, but could be included? For example, managing IT architecture, metrics and KPIs, and even IT services. True, these are already such borderline functions that they can be safely taken out of the horizon of this article.

DevSecOps engineering tools

Here the set is generally standard. Let’s add a level of detail, but we will not describe each sub-item, they are already obvious.

2.1. Orchestration of automated operations

2.1.1. Continuous Integration (automation of assembly and deployment
to development environments)

2.1.2. Continuous Delivery (automation of deployment to test environments, launch of autotests)

2.1.3. Continuous Deployment (deployment automation for acceptance and prom environments)

2.2. Code Management

2.2.1. Managing source code, test code, and deployment code

2.2.2. Static code analysis

2.2.3. Obtaining the vendor’s source code

2.2.4. Unit test automation

2.3. Performing an automatic build

2.4. Internal APIs (interfaces of integration interaction)

2.4.1 Managing internal APIs

2.4.2. API documentation

2.4.3 API test automation

2.5. Managing Development Artifacts

2.5.1. Delivery of external libraries

2.5.2. Storing intermediate build artifacts

2.5.3. Obtaining vendor distributions

2.5.4. Storing distributions/images (docker registry)

2.6. Deployment and configuration

2.6.1. Deploying and configuring applications

2.6.2. Database Configuration (DDL/DML)

2.6.3. IC configuration storage management

2.6.4. Secret Management

2.7 Testing

2.7.1. Test management

2.7.2. Test data management

2.7.3. Orchestration of automated testing

2.7.4. Functional testing automation

2.7.5. Load Testing Automation

2.7.6. Load monitoring

2.8 Application Security (secure development)

2.8.1. Control of Open Source artifacts (vulnerabilities in libraries)

2.8.2. SAST (static code analysis for vulnerabilities)

2.8.3. DAST (Dynamic Vulnerability Analysis of IP) / IAST (Interactive
Vulnerability Analysis)

2.8.4. BAST (control of fulfillment of information security requirements)

2.8.5. WAF (feedback from Web App Firewall)

2.8.6. Distribution/container control

2.9. Application monitoring

2.10. AIOps (Artificial Intelligence for Operations) – well, this is already a border function with IT infrastructure management. But at the request of the workers, we included it in the scope.

Monitoring

There are other areas of monitoring that are not included in the previous paragraphs. We have identified two:

3.1 Monitoring processes and engineering practices

3.2 Process Mining

The development process and related processes can fail. It is necessary to quickly monitor what has fallen off where, and take action. Organized monitoring is indispensable here.

So what did we get? A fairly detailed map of the functional tasks of the software development process, which can be used to assess the coverage of these same tasks with automation tools. It remains to build it into a matrix, dividing it into semantic blocks.