Saturday, 19 April 2014

DevOps for the Large Organisation

DevQops

dev·qops     \ˌdɛv-,Kops\
: to undertake "DevOps" with particular impetus on Quality Assurance (QA), ideal for the larger organisation with rigorous QA processes and sophisticated, multi-tiered IT systems.


Example: "I use DevQops since DevOps didn't quite address my development, quality assurance and IT operational needs."


DevQops v. DevOps

Wikipedia describes DevOps as:
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals.

Without trying to be overly simplistic, the emphasis here is the interaction between developers and operations. Since DevOps is still relatively immature in the IT industry, the general consensus is to focus on the literal interpretation; communication, collaboration and integration between developers and operations.

In my opinion, DevOps is the latest 'branding exercise' to encompass Continuous Integration (developers) and Continuous Delivery (operations). In theory this makes absolute sense; submit small changes frequently by the developers (without breaking the application) and implement in Production frequently.

DevOps encompasses both Continuous Integration and Continuous Delivery


However, I believe this approach is only suitable for a subset of all organisations, those that develop relatively simple systems with a short route to Live. For organisations that have large, complex, multi-tiered systems - such as Financial Services, Telecommunications, Utilities, Retail and Gaming organisations - it is likely that rigorous QA processes are in place to address various methods of testing, such as:
  • Systems Integration Testing,
  • Regression Testing,
  • User Acceptance Testing,
  • Penetration Testing,
  • Load Testing,
  • Functional Testing,
  • Smoke Testing.

Once these levels of QA are introduced, the ability to frequently make changes and deliver changes is somewhat restricted.

System architectural example  

If we consider the example above; this could be a typical financial system topology which might represent a single QA stage (a single test-rig) within the overall software development life cycle. As a minimum - and for the purposes of this example - let's assume this particular organisation undertakes at least four levels of testing:
  • Systems Integration Testing,
  • Regression Testing,
  • User Acceptance Testing, and
  • Load Testing.

In terms of complexity, change management and environment management, it is my belief that the QA managers have a far more difficult job than even the Operations team - the Operations team, while important, typically only have to manage a single version of any given system within a single environment, Production.

The QA team has the more complex and demanding role of having to:
  • Manage multiple versions of a single application,
  • Manage multiple applications simultaneously,
  • Manage multiple test-rigs simultaneously, and
  • Co-ordinate all of the above to ensure testing is completed within the agreed test duration.

If the QA element cannot be managed efficiently (streamlined and automated) then it effectively renders Continuous Integration and Continuous Delivery nigh on useless - as per Kanban, your process is only as effective as your greatest bottleneck.

So, to get to DevOps nirvana (DevQops) one has to assess the processes surrounding QA. In my experience the most common issues are around:
  • Managing "change-sets"; a collection of small changes from development scheduled for delivery,
  • Infrastructure Management; provisioning required infrastructure to support altered application(s), and
  • Application Deployment; implementing changes from development - or other test stages - into desired test-rig.

These common issues are not difficult to manage in themselves, but when applied to a large organisation with hundreds, if not thousands, of servers, test-rigs environments and applications, then the task becomes brittle, cumbersome and resource-intensive [costly] to manage.

I will dedicate a future Blog on "How to Implement Fully Automated DevQops".