This is my final blog in the three part series (part 1, part 2) for reaching a point where we can get an idea of what are the pieces that roughly make up continuous delivery. There is one last piece that I feel that still gets push back in the Enterprise.
Agility vs. Governance
Agility or governance? Maybe both? DevOps is basically letting your sys-admin’s and developers intermingle. Traditionally, maybe the pre-21st century, this had been absolute heresy have these people work together.
Strict processes had highly emphasized segregation of duties of Developers, QA, security, and Operations (Basis). Guess what? Mix that crew together and allow some cross-contamination and all of the sudden there is a lot more doing or innovating, hurdles go by faster, and because our goals are the same, there is a lot less finger pointing. Highly effective DevOps teams are limited in size, they have the “just do it” attitude, and they will fix it fast. Once given trust and a state of self-control, each member’s sense of accountability starts to rise.
OK, so now I have sung the praises of DevOps, the fact is that there are regulatory bodies and change controls that can’t be completely ignored. I am not suggesting that we all become Sys-Admin Developers with security certifications and stop listening to some of the conventional wisdom, but we want to be agile and deliver faster. So let’s distill that wisdom and do more with less.
Change Process
Remember, change processes have been put in place to slow down change so it can be digested and discussed. Usually, because massive amounts of code are being released at once. For many reasons, this complicates a reasonable reaction time for a support organization. At the most fundamental level of SAP development, this type of release strategy is reinforced by ABAP development. Objects are locked when they are being manipulated because the current change tracking implementation is limited, thus preventing any sort of distributed workload. (So much so that organizations have been forced to spend enormous amounts of money to create multi-tiered landscapes to handle the amount of change they need.)
We know that coding requirements and test cases can be recorded using Test Driven Development. The usefulness of this is so much greater than documentation that could be too large to digest, or not existent. We know that we can automate testing so that anytime we make a change. Once a change is ever introduced, it is tested, and if it breaks, we drop everything and fix it now. We know that deployment should be easy because of our automation. Testing, solution reporting, and deployment were automated to do more with less. And if it breaks in production, we can roll it back immediately because we planned for that using our versioning tools.
DevOps Culture
DevOps teams create a culture that:
- Builds quality in early as possible
- Continually looks to reduce technical debt, and therefore reduces their cost of ownership
- Shares responsibilities and works more collaboratively
- Openly accepts feedback
- Breaks down knowledge silos
- Builds up team autonomy
I am sure if you stuck with me through these, there were points that make sense and others that were kind of fuzzy on how it would work for your organization. I won’t say that every piece may fit your software lifecycle, but if you’re passionate about robust high-quality software and you won’t settle for “good enough”, then I think these points might have hit home. Let’s be honest… as a user, product owner, engineer or architect we will always come up with some idea to make our apps and our lives better.
How about you?
Have you had success with Continuous Delivery or TDD? How about DevOps? Please leave comments if you have some nuggets of wisdom or success stories to share.
