Our resident expert on enterprise mobility and mobile application development, Peter Rogers, shares his insights on the subject of Enterprise Mobility and DevOps in this guest post. Enjoy!
*****
A lot of people say the word “DevOps” but there is very little material that actually defines what it
Peter Rogers,
Mobile and Digital Expert
Cognizant
actually means. It actually transpires that DevOps and Enterprise Mobility were a match made in heaven. This is because the current trend is for enterprise mobile services to go live in 3-6 months and requires a whole new mindset.
“DevOps is a software development method that emphasizes communication, collaboration (information sharing and web service usage), integration, automation, and measurement of cooperation between software developers and other IT professionals. The method acknowledges the interdependence of software development, quality assurance (QA), and IT operations, and aims to help an organization rapidly produce software products and services and to improve operations performance”
https://en.wikipedia.org/wiki/DevOps
“Gartner believes that rather than being a market per se, DevOps is a philosophy, a cultural shift that merges operations with development and demands a linked toolchain of technologies to facilitate collaborative change. Gartner views DevOps as a virtual (and likely temporal) market and has focused the scope of the definition on tools that support DevOps and practices associated with it in the context of continuous delivery, continuous improvement, infrastructure and configuration as code, and so on. Gartner categorizes these tools as DevOps-ready, -enabled and -capable tools.”
http://www.gartner.com/newsroom/id/2999017
DevOps is a suitably vague term and I think over the years it has become an umbrella for more definitive terms that have started to appear in the Mobile and Web spheres:
· Test Driven Development
· Behaviour Driven Development
· Automation
· Continual Deployment
· Client/Server Application Monitoring
· Agile Project Life Cycle
The idea around DevOps is to give developers more operational powers in order to deploy software more autonomously. Typically in an old school Waterfall Approach:
1. We write our code
2. We run Unit Tests to an unknown level of Code Coverage
3. We run Integration Testing
4. We run System Integration Testing (SIT)
5. We run System Testing
6. We run User Acceptance Testing (UAT)
The problem with this approach is that to take a feature live then it is actually incredibly expensive in terms of testing effort. Most mobile projects do not last more than 6 months and so the budget just isn’t there for this drawn out linear approach. Wouldn’t it be smarter to put the power in the hands of the mobile developer to be able to safely deploy a new feature without all this hassle. Well it all depends if you trust your mobile developers. In order to be able to achieve this goal then we must pick the right methodologies and the right tools to empower the developers.
The new methodologies of Test Driven Development (TDD) and Behaviour Driven Development (BDD) provide us the strategy and are supported by toolsets. In Test Driven Development a developer must define a test for the software unit first, then implement the code unit and finally verify the implementation through the unit tests. The responsibility lies with the developer to make sure the software unit is delivered as a working entity in an atomic transaction. TDD not only hands unit testing to the developer but it also makes them think about code design upfront. Mobile projects are particularly susceptible to future support issues because the focus is often based around getting the App out there yesterday without any consideration of what happens 12 - 18 months down the line. TDD ensures that the code has adequate test coverage and the tests also act as a form of documentation, which is particularly handy when you find there isn’t any.
Behaviour Driven Development is a superset of TDD which enforces a higher level of collaboration between the core groups within an Agile scrum: developers; tester; user experience specialists; business analysts; and senior managers making sure a software contract is fulfilled. Mobile projects require a very strong user experience but this is difficult when your developers, business analysts and designers all talk a different language. Using BDD we can actually communicate a shared vision that enforces a business-coherent and a user-friendly experience.
“Behaviour Driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development. BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters”
https://en.wikipedia.org/wiki/Behavior-driven_development
Test Driven Development (TDD) gives us the following:
· The developer writes the unit tests
· The unit tests are written before the code
· There are defined levels of code coverage which are generally 80% or higher
· Mocks are used for Black Box testing and to help with asynchronous testing
· Unit tests are typically automated and fast to execute - at least on the developer’s machines
Behaviour Driven Development (BDD) gives us the following:
· A common language that can be understood by business analysts, user experience specialists, testers and developers
· A feature driven approach to development that includes business level top-down design
· Complete traceability of business requirements against software features
· Automated acceptance tests
OK, so through TDD and BDD we have empowered developers and allowed them to talk in a language that the rest of the world understands, most importantly the business. We have definitely put more work on the developers but we have elevated their status in life. If a senior manager actually understands the business value of what the developer is building then they are most likely to get higher praise. But how do we get rid of the traditional System Integration Testing and User Acceptance Testing phases which slow down the deployment of new features? Well this is where Continuous Integration, Continuous Delivery and Continuous Deployment come in. This is typically a challenge in mobile projects because everybody wants to see the App regularly and getting the App to the end user is not always trivial. This normally results in out of date versions of the application being circulated and vast quantities of defects being based that were already solved days ago.
“Continuous Integration is the practice of merging development work with a Master/Trunk/Mainline branch constantly so that you can test changes, and test that changes work with other changes. The idea here is to test your code as often as possible to catch issues early. Most of the work is done by automated tests, and this technique requires a unit test framework. Typically there is a build server performing these tests, so developers can continue working while tests are being performed.”
“Continuous Delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship. This could be UAT or Staging or could be Production. But the idea is you are delivering code to a user base, whether it be QA or customers for continual review and inspection. This is similar to Continuous Integration, but it can feed business logic tests. Unit tests cannot catch all business logic, particularly design issues, so this stage or process can be used for these needs. You may also be delivering code for Code Review. Code may be batched for release or not after the UAT or QA is done. The basis of Continuous Delivery is small batches of work continually fed to the next step will be consumed more easily and find more issues early on. This system is easier for the developer because issues are presented to the developer before the task has left their memory.”
“Continuous Deployment is the deployment or release of code to Production as soon as it is ready. There is no large batching in Staging nor long UAT process that is directly before Production. Any testing is done prior to merging to the Mainline branch and is performed on Production-like environments, see Integration blog article for more information. The Production branch is always stable and ready to be deployed by an automated process. The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button). After a deploy, logs must be inspected to determine if your key metrics are affected, positively or negatively. Some of these metrics may include revenue, user sign-up, response time or traffic, preferably these metrics are graphed for easy consumption. Continuous Deployment requires Continuous Integration and Continuous Delivery - otherwise, you are just cowboy coding and you will get errors in the release.”
http://blog.assembla.com/assemblablog/tabid/12618/bid/92411/Continuous-Delivery-vs-Continuous-Deployment-vs-Continuous-Integration-Wait-huh.aspx
With Continuous Integration we have eliminated the need to have a dedicated System Integration Testing phase, as long as our automated unit tests, integration tests and system tests are strong enough. Typically adhoc testing would be performed at the same time by quality assurance testers and most system tests are typically manual as they are difficult to automate in practise. With Continuous Deployment we have eliminated the need to have a dedicated User Acceptance Testing phase, as long as we have used BDD automated acceptance testing and we can truly deploy the application to any target user at the press of a button.
There is a piece of the puzzle missing and this is Integration Testing which is the Achilles’ Heel of every mobile project. If something breaks in an enterprise mobile project then you know that 99.9% of the time the finger is pointing at your mobile application. What is more annoying is that 99.9% the problem is located somewhere else and you just can’t prove that fact. Well the way out of that particular Catch 22 is to provide an effective integration testing solution.
Typically integration testing is performed in a rather convoluted way through permutations of components talking to each other. This gives rise to a vast amount of tests which are often slow to run and at the end of the day nobody knows where the fault lies when they fail. Luckily there is a much better approach to Integration Testing and this is described in a beautiful one hour video which anyone who is serious about testing should really watch. In a nutshell instead of Integration Testing you should treat each component as a black box and perform Collaboration Testing and Contract Testing. Collaboration Testing makes sure your component is talking correctly to another component. This is achieved by defining an interface for each component for the services it offers. Contract Testing makes sure that the component you are talking to actually honours the contract. It is probably easiest to think about this as a client-server model.
https://vimeo.com/80533536
Let us imagine the simplest mobile application in the world. We have two boxes: a mobile library which handles networking to a server; and a remote server that responds with JSON data. This is a true client-server mobile application scenario to make it easier to understand but in practise this will involve many client components talking to each other before an outside server is even reached. Let us say the remote server offers a REST based API. We can now perform Collaboration Testing on the mobile library to make sure it calls the REST API correctly. Most people normally forget the other half of the equation, which is making sure the server is well behaved. This is why the mobile client ALWAYS gets the blame and it can be prevented very easily. We can perform Contract Testing on the remote server in this instance by making sure that it responds correctly to the API calls. You should set up some kind of service monitoring here. You should also check that the JSON data returned meets the agreed contract and this is where JSON Schema come into play. You can define precisely what are acceptable responses from the remote server as opposed to just expecting the client to be 100% defensively coded.
If we imagine that we start with the first component in an enterprise solution and then we work our way down through a tree-like structure of component interactions then as long as we test each individual software unit and perform a collaboration test with each other unit it talks to and a contract test for each unit that talks to it…then we should have a perfectly tested system. Why is this important? Well it removes the whole entropy of integration testing and seeing as we are testing against interfaces then most of the time we can treat the components as black boxes and use Mocks. This means we can now perform automated integration testing as opposed to winging it. It also means that the code is designed better because we can spot the limitation in the component contracts at design time rather than build time. Finally it means we have a break out loop from the Blame-Mobile-First approach.
At the end of the day we have just empowered a team of developers to create a fully tested unit of software that implements a well-defined feature that has traceability back to a well-defined business requirement, which is fully tested against all the other software components and merged into the main software product safely. Furthermore we can actually move that software release through various stages of deployment automatically, including a full production release (knowing this has been tested against acceptance criteria that all parties have bought into) and have the resulting application ready to deploy at the press of a button. I think THIS is what people mean by DevOps and THIS is why it is critical to modern day mobile development.
************************************************************************
Kevin Benedict
Writer, Speaker, Senior Analyst
The Center for the Future of Work, Cognizant
View my profile on LinkedIn
Read more at Future of Work
Learn about mobile strategies at MobileEnterpriseStrategies.com
Follow me on Twitter @krbenedict
Browse the Mobile Solution Directory
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies
***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.
Kevin Benedict,
Senior Analyst, Digital Transformation, Cognizant
Follow me on Twitter @krbenedict