The relationship between Development and IT Operations is a mutually inclusive one in that a decision that is made on one side can effect the other, not always for the better.
With all the focus in the world of DevOps seemingly on the Operations and infrastructure side I would like to take a moment to discuss some of the fundamental issues that can effect how your DevOps process is rolled out if focus isn’t also applied to Development as well.
Moving an organisation away from Waterfall to Agile is no mean feat. It entails a dramatic shift in mind sets and organisational culture. The adoption of new methods of working will cause many to find it overwhelming if thrown right into the deep end. Fortunately the saving grace of DevOps is not only to help them move towards incremental changes to their products but to do so in small managed incremental changes it’s self. Lead by example.
Yet even managing this transition of your infrastructure in bite sized digestible chunks can be thrown off track if fundamental issues in Development aren’t addressed first.
Development first
You have your new green field project and the go ahead to “do the DevOps thing”. It’s time to plan your infrastructure right?
Not so fast, and here’s why.
While your Development team may already be functioning in an Agile fashion, holding scrums, code reviews and automated testing within their own controlled environments, it may not always mean that what is being produced by Development is in a state that can be readily absorbed by your engineering teams to deploy to live. And this can be the root cause of many poor Infrastructure design decisions.
The usual Waterfall environment map may have anything between 5-7 environments to validate the build, stability and acceptability of release candidates. In that world you have a lot of quality gates to capture poor releases and as release cycles can stretch into months there is always time to capture defects and get them fixed before they hit production.
Under Agile our goal is to reduce that lead time dramatically and shorten the development cycle producing features on demand as and when they are required by the customer. All good in theory, however it also means removing a lot of quality gates which until this point have been helping you stop poor release candidates getting through the door. Under this scenario it can be the natural response for the architect to add additional quality gate environments into the map to help capture those instances. While all good in theory, this is not the ideal response when trying to create LEAN, Agile infrastructure. Instead of saving money, you will end up spending more on those additional environments to try and capture these bad RC instances. In effect Infrastructure is still having to over engineer to protect themselves from bad development practices.
If this sounds familiar to you then your work with Development is not quite over. In my experience I’ve identified the following key areas to sanity check and help drive better release candidates
Automated testing
There is no question as the importance of testing your code. BDD and TDD will help developers create more efficient LEAN code, but are they testing correctly?
There is a world of difference between Unit and Functional testing and they should both be used in tandem. While Functional testing can give you a good idea of how the code is functioning as a whole, without Unit tests it becomes harder to validate the individual stability of each component and you could be missing some important information to help diagnose bugs and defects. For example a method could be changed in a controller which causes methods in a model to behave differently. Without Unit tests to protect the individual functionality of each method it is harder to diagnose where the fault is if the developer who implemented the change is unavailable.
Code review
I really can’t stress how important the role of the code review is to the release process. While automated testing can capture issues with the functionality of code at the high level, it is difficult for automated tools to definitively assess whether the written code is of a high enough standard to pass through to production. A more senior developer should always review code to ensure that what has been written meets coding standards, does not contain hard coded passwords and is of a sufficient quality to merge into the next Release Candidate.
Post-release feedback
Lets say that a release candidate has gone through the testing phases without incident but then is deployed into Production and something goes wrong. A fix is found and the release is finalised. Is that information being passed back to Development?
This sounds like the most basic of concepts yet in too many organisations I’ve worked with, this fundamental and crucial stage in the release process is missing. It’s an area that underlines the importance of a proper implementation of DevOps methodologies. In the test case we looked at earlier where Infrastructure are over engineering environments, it could simply be that the Developers have not been informed what went wrong therefore continue to make the same mistakes. Putting in place that feed back loop allows the Developers to raise these issues in code reviews to ensure that the defects encountered can be alleviated in future.
The onus is now back on the Development team to fix their process but in a manner compatible with shared ownership as the Ops/Infrastructure team are actively engaged with Development to resolve release issues at root cause. The dialog then allows Architects to simplify the environment map to the Minimum Viable Product so that extra environments aren’t required to try and catch development mistakes.
Summary
Effective communication is vital at all stages of the release process and attempting to fix fundamental development issues by over complicating infrastructure is most definitely not the correct way to go. DevOps should always be used as an aligning tool to bring both sides of the product cycle into balance and ensure successful growth and stability.
