We are robots – what managers of DevOps teams really want

Back in 1978, when Kraftwerk performed their “we are robots” song, I hadn’t even started my professional career yet. During my career as developer and in software quality assurance
(starting in 1992) testing was very costly and often needed manual tasks.

The idea of being assisted by robots in programming and testing has become more common in the last few years. But till then unit-testing and regression-tests were a troublesome business.

Here you can watch a typical Kraftwerk performance of that time:
https://www.youtube.com/watch?v=S2dULojeh7Y

The approach of that time to make this kind of electronic music was revolutionary. Kraftwerk as a band were 4 buddies.

2 buddies

If we look at a typical DevOps approach there are parts which are done by the DEV side and others which are processed by the OPS side. These 2 sides aren’t naturally born enemies but should also be buddies.

See the following figure to get an overview of the different phases, that are part of a typical DevOps tool chain. The left side is typically seen as the DEV’s responsibility, the right side belongs to OPS.

Between plan, code, build, release and deploy there is the test automation phase, for which it should be easy for an assistant or servant to do the appropriate work. If all the tests are passed and everything is fine, my part of a “wave” (several sprints) or “sprint” should be marked as deployable. Until that time all that is left is wishful thinking.

Reality-Check

In April 2016 SAP announced the availability of the SAP Focused Solutions. It was the first time at the SAP Solution Manager Education Summit 2016 – late in that year – where the idea of SAP using DevOps and a scaled agile approach was presented to a wider audience. I wrote about the Solution
Focused Build in the blog post https://blogs.sap.com/2018/04/03/sap-focused-build-how-to-get-more-flexibility-and-agility-in-your-sap-projects/. Flexibility and agility with SAP methods were the main topics there. There is a test planning and kind of execution automation build-in SAP Solution Manager. Changes are recorded, test cases that need to be retested are recognized. But it’s up to you to do the right tests. Automatic testing, supported by assistants could serve here.

2 more buddies

Automatic testing and SAP Focused Build could be two more best buddies. E.g. for CI/CD.

Continuous-Integration (CI)

If I think about “continuous-integration” (CI), which is part of any agile approach and even SAPs preferred way – in environments outside of SAP – I can see some serving solutions like Jenkins.
Isn’t it interesting that this company has chosen a servant as their logo?

Kraftwerk states “Ja tvoi sluga” which is Russian, meaning “I’m your servant”.
The advantages of such a toolset – serving you – could be:

… build and test your software projects continuously
(source: https://wiki.jenkins.io/display/JENKINS/Meet+Jenkins)
… continuous integration (CI) and continuous delivery (CD)
… making it easier to integrate changes to projects.

This is the more sophisticated approach I’ve been searching for in the SAP world.

Beyond automation

Never underestimate the availability of the right toolsets. But be aware of all the other pillars of a successful DevOps approach named in the CALMS framework. The abbreviation CALMS starting with the “C” means Cultural change (C), automation (A) in testing, release-management, building, deploying (A), Lean methodologies (L), Measurement and KPIs (M) and sharing (S).

Please see my blog post https://blogs.sap.com/2018/03/01/keep-calms-and-do-mindful-sap-devops/.

Let me just emphasize the different point of views in a DevOps optimization approach again.

The perspective of a developer – DEV side

As a programmer I wish to have everything retested automatically, after I finished my coding.

The song-text by Kraftwerk goes on like …
“… We’re programmed to do anything, and anything you want is done.”
Please imagine, that the robot will do the regression tests automatically. That would be a dream coming true!

The perspective of an operator – OPS side

Only stable parts of a release – ideally without the toil of building and integrating –
should be imported into the production environment – or even better as a trial rehearsal into a
pre-production system before. See google’s view on toil:
https://landing.google.com/sre/book/chapters/eliminating-toil.html.
(e.g. manually running a script that automates some tasks).

At least the perspective of a manager

As a manager I should do everything, which is under my control to let go. To give trust to the team and to ensure that the team has all the abilities at hand to decrease manual effort for test-scripting. In the end I want to sleep well, also during deployment times.

About trust

” … Trust is the foundation of DevOps …” (original quote by Dirk Lehmann) here
https://blogs.sap.com/2018/06/19/trust-is-the-foundation-of-devops/ . And he is absolutely right.

It would be much easier for me – as a manager – and also the team, if we could rely on servants, which care about the consistency of our software application. And therefore earn that necessary
trust by quality and stability.

DEV#OPer’s dream

Being a Dev#Oper, it would be my dream, that my managers can sleep well, because there is trust in the Dev#Oping team, based upon …

• Tests will be processed automatically based on historical behaviour of my system
• The deployment won’t break the productive system
• All my mission-critical processes will work as before – after a successful deployment
• The deployment will be stopped, if an error or unforeseen situation is detected in
  re-testing
• Due to the DevOps approach the quality at the end of the “continuous delivery pipeline” will become better and better

The Solman can do it. Turn it ON again!

To be honest, maybe there has to be some additional tools for the automatic regression-testing.