Continuously Optimizing your DevOps Processes

Investigate if the process from gathered feedback to concrete backlog items can be enhanced, and how to provide transparency along the complete lifecycle, which initial requirements an increment addresses. Ideas include looking into tools for agile project management and changing documentation capabilities, such as those offered by SAP Cloud ALM.

Continuously investigate options to extend and evolve your development approaches, such as by approaches that foster clean code, test-driven, or behavior-driven development.

Consider defining KPIs for your pipelines and constantly investigate them to identify optimization potential. For example, do all your changes qualify for pipelines? How long do they run? Is it possible to split long-running pipelines, as not all automated tests must be performed for every change, but test results for certain aspects suffice once a day?

Increase your overall test coverage. Check what issues came up in later stages of production, and consider adding other tests to avoid such late surprises.

Continuously check for new or updated compliance requirements and see if they can be reflected automatically in corresponding tests.

For your transports, investigate if there would be further use cases that should be handled by having a hand-over into transport management–for example, as extra content types have been enabled for transports by SAP Cloud Transport Management service.

For existing transports, evaluate the need to automate deployments into specific landscapes (such as scheduling transports into QA and TEST accounts or performing direct deployments using SAP Continuous Integration and Delivery service for development scenarios where no additional control is required).

Regularly evaluate and update configured permissions for critical target landscapes.

Evaluate the need for extra change management, such as quality gates or handling strict public cloud, private cloud and on-premise change interdependencies.

Think about introducing feature toggles to handle the release process of deployed changes.

Implement broader monitoring by instrumenting your applications and by combining local observability capabilities (as offered by SAP Cloud Logging service) with central observability, provided by SAP Cloud ALM. This will allow you to check the health status of your apps, even if they should span several environments, and can drill down for a context-sensitive log analysis, if necessary. Make sure you get notified of upcoming potential issues or failures, using SAP Cloud ALM in interplay with SAP Alert Notification service for SAP BTP.

Make the pursuit of automation potential part of your retrospectives.

For this, investigate recent Ops tasks you had to perform to operate your app: What actions were required? Could regular manual tasks be automated, for example by using SAP Automation Pilot – or to create automated self-services for setting up new team subaccounts using Terraform provider for SAP BTP?

Also, in your investigation to identify further automation potential, include manual tasks you had to perform to remediate recent issues. Can we come up with additional recommended actions? Ideally bound to events and metrics, so that SAP Cloud ALM could automatically trigger those actions on SAP Automation Pilot when needed.

To foster automation, get inspiration from the latest automation content and example use cases (from SAP or other teams) .

Do you have transparency on how your software is used? Add feedback channels and questionnaires to your product. Think about how to reach out to your end users (such as via communities, events, and direct exchange to get into direct contact with them).

Remember the CALMS acronym? It comes from Culture, Automation, Lean, Measurement, and Sharing.

Occasionally, take two steps back to evaluate overarching processes and other CALMS principles. For example, is there enough room for a regular exchange with different teams (within your company and with external parties)? What are the latest market trends around DevOps, developer experience and automation? Are there extra blockers concerning your cultural transformation? Where are other areas standing, and how does this affect your team? How does the onboarding of new teams work today? Might a platform team make sense?

How is your team doing in terms of its DevOps approach? Would KPIs, such as DORA KPIs, help identify further optimization potential? Is there enough room for retrospectives and exchanges with other teams? Are there other ideas on how to optimize?

One proposed idea was to reduce the number of test cases so that changes could propagate faster.

What do you think, is this a good idea?

Time to delivery is not the root cause for the issues faced here, but the quality of the changes. Therefore, the team will investigate whether the number of automated test cases could be increased. For every issue that comes up, the team will investigate whether the root cause can be identified during development with automated test runs. For new code, they will consider test - or behavior-driven development approaches.

They will also evaluate how much code is automatically tested. This will allow more issues to be identified and fixed before propagating to the runtime, reducing the number of issues that arise in the production environment.

Another proposed idea is that the team should focus on increasing manual monitoring efforts to become more aware of issues quickly. Have you imagined a similar or an alternative solution before?

Instead of increasing efforts for manual monitoring, the team decided otherwise:

1. Subscribe to all events that are relevant to the app on SAP BTP, such as:
   • events from used SAP BTP services,
   • events from the infrastructure provider on which the SAP BTP account runs,
   • events from the used SAP BTP runtime environment.

   Here, you can check, for example, events offered by SAP Cloud ALM ] and SAP Alert Notification service for SAP BTP.

2. Ensure the relevant alerts reach the DevOps team via the proper channels.
3. Make sure that teams can easily drill down from their central observability view to local observability for root cause analysis - as from Health Monitoring in SAP Cloud ALM to SAP Cloud Logging service.

This means establishing a reactive way of working, reducing the time needed to become aware and fix issues. It will also free up resources that otherwise would have to be spent for active monitoring.

Next, they discussed whether the team looks for optimization potential around manual operation tasks. What is your take on this topic?

As you may have presumed, the team decided to investigate which manual tasks were required to find the root cause and fix those issues.

Then, they will select the manual tasks that could be automated so that automated remediation can be automatically executed the next time such an issue arises - triggered from SAP Cloud ALM or by other events.

Also, recommended actions will be created in SAP Automation Pilot that could get triggered from SAP Cloud ALM or manually whenever the corresponding tasks must be performed, with less effort and with repeatable results.

For Rotating Banana, all these decisions and actions ultimately led to higher satisfaction for the DevOps team and appreciation from its customers!