DevOps is quickly becoming one of the most valuable disciplines for your business. It’s focused on improving the quality and speed of delivering new applications to market for your consumers to leverage.
If you want to know why and the things you can do to ensure it is effective for you, you'll love this blog.
Lets dive right in...
Is DevOps Right For You?
Businesses everywhere are taking a second, third and even fourth look at what they initially thought was a buzz word - here one day, gone the next!
Now everyone is wondering “Can we adopt a DevOps method ourselves? Will it work for us?”
So what can DevOps do for you?
What Is DevOps?
Before we decide if we can use DevOps, we must define what DevOps is, and what it is not.
DevOps is not a product, or even a particular technology. DevOps is a methodology that unites the often separate capabilities and functions of software development (Dev) and production/operations (Ops) into a single, integrated, and continuous process.
DevOps is about breaking down the barriers between Development and Operations. It leverages people, processes, and tools to stimulate collaboration and innovation across the entire software development release and support process - Development and Operations must act and feel like they are a single team!
But DevOps is never finished. Development and Operations must keep pushing and collaborating in the pursuit of perfection.
Is Dev And Ops On The Same Page?
Development is focused on faster innovation and doing new things at pace and the mandate to Operations is about stability, control, and predictability - it almost feels like a conflict of interest if we take the simplest of views.....
They often don’t even report to the same places in the organisation and It is like they are on two different train tracks - No matter how fast they go, they never meet.
Left to themselves, Development and Operations will often struggle to talk to each other, be much less collaborative, and will remain absorbed in manual silos until they are forced to talk (transition???).
No if’s, and’s, or but’s about it.
7 Signs Of A Dysfunctional Way Of Working
Development and Operations on the same page and heading in the same direction —can be difficult. But first, as we said above, you have to recognise if your teams are on different tracks to begin with. From working with our customers over the years who were struggling to bring the 2 areas together, we see the following 7 warning signs:
You don’t discover software defects until late in the lifecycle—or worse, in production!!
You use Agile to speed development, but any gains evaporate once the application goes into production.
Your developers and testers are constantly waiting to access the resources they need, causing delays.
You can’t pinpoint problems across development, testing, and production operations.
You see simple human errors wreaking havoc during development and deployment.
Development view their job as finished once the application is in production.
Anytime a problem arises, everyone starts pointing fingers to lay blame on someone else.
So, lets take a deeper look at the 7 warning signs...
You don’t discover software defects until late in the lifecycle
The cost to fix a defect goes up for each step along the classic waterfall approach to software development. It can be one hundred times more expensive if an end user finds a major defect in production than if you find it in development.
Unfortunately, with the waterfall method, when the development schedule starts to slip and there is a hard deadline looming, organisations start to run out of time for testing. This situation is ripe for error, and the pressure to meet the deadline means that the application suddenly gets thrown over the wall into production, no matter how complete the testing is.
what can we do?
Do testing and development in parallel! This is made possible through a new technological approach called service virtualization that can mimic the real-world behaviour of the production environment. The real infrastructure resources are not available to developers and testers, so this approach recreates the whole environment in a virtual environment. The back-end infrastructure, databases, servers, and the rest of the environment are available as a virtual service, so a large number of people can test a large number of components all at once without impacting each other or the production environment. Suddenly, development and testing can take place in parallel.
This ability to mimic the performance of the production environment is made even more realistic through collaborative data mining, where the performance information embedded within the production environment is “mined” to uncover hidden patterns and circumstances.
Data mining gives developers and quality engineers virtual service models that behave even more like the real world, bringing all the benefits of service virtualization with performance profiles mimicking business conditions and scenarios like the ones seen in production. Now, developers and performance engineers reduce their constraints and do so with an increasingly life-like model emulating behaviour and the performance characteristics of real components in real-world situations as well.
Find the problems earlier, and you build better software, faster, with less effort.
The speed gains of Agile evaporate once into production
Agile development is a fabulous approach to speeding software development. But building the software is only one step in getting an application into the hands of the users who need it!
Because of the lack of collaboration between Development and Operations, applications often aren’t ready for “prime time” when they arrive in production because Ops often hasn’t been involved in development and therefore doesn’t fully understand how to deploy support and maintain the application to production.
Development alone doesn’t get the app into the hands of the user. No matter how fast and agile you make the development process, it is difficult to speed time to market if nothing is done to speed time to production.
what can we do?
Agile is built around an iterative process that responds quickly to market needs. The idea is to roll out frequent incremental changes rather than save all the changes up for a big splash (waterfall).
Agile operations would never dream of developing an app without paying close attention to market needs. however, they should pay similar attention to the needs of the production environment. Development and testing should also take place in as life-like (production-ready) an environment as possible.
Another potential source of trouble is completing steps serially. Even in the most agile of development environments, there are times when work is largely done in stages - such serial processes can slow both development and deployment.
Teams should be working in parallel as much as possible, and in places where you can’t break things into parallel efforts - look for ways to move steps earlier into the process. There is no reason why Operations should be waiting for Development to finish before it starts working on deploying the application; involve Operations early and plan for deployment during the development process.
Teams are awaiting for resources leading to impacted schedules
Whenever a complex application is being built it is probably making use of information pulled from other systems and services throughout the enterprise.
Developers and testers often can’t get easy access to these services. It could be that back-end systems, like the inventory system, are only available for test access once a week for two hours at a time. Or maybe there’s sensitive data in a production system that either shouldn’t or can’t be touched. All of those are serious constraints on the process of development and testing an application.
what can we do?
Because service virtualisation can mimic the real-world behaviour of the production environment it enables a large number of people to develop and test a large number of components at once without impacting each other or the production environment itself.
This removes the constraints that are holding back application development and testing in many organisations. Not only is the testing environment now a much more realistic reflection of real-world conditions, it also enables testing of different components to be done simultaneously. Steps that once had to be done serially can now be done in parallel!
Struggle to pinpoint problems
Teams in Development, Testing, and Production often work in very different environments and manage their work on different workflow systems such as Jira and ServiceNow. This can make software defects difficult to correct.
Because development teams and testing teams often don’t have reliable access to the production environment, they rely on test environments that, while they might offer the functionality of the production environment, lack the full scale of production. These are not realistic testing environments that duplicate the conditions found in production, so applications often fail when taken to production because the earlier tests are not predictive of the applications real-world behaviour
Also, because Operations, Development, and Testing all use different systems to manage their environments and workflows, the feedback loop that should be in place between Operations and Development breaks down.
Operations knows there are problems with the application, but unless someone in Operations bothers to tell Development about the defect, Development will never know about it. Development cannot monitor the application in production itself, so it only gets a second-hand perspective on any problems..
what can we do?
First, recognise that Development and Operations are part of the same lifecycle and cant work on separate islands . Even with this organisational change,
establish a process to gather feedback and then track and share progress on
addressing the issues.
You can take the next step and use technology. It’s all well and good to
address People and Process, those of you who know us, we constantly voice that its all about People, Process & Tools!
Technology can take several forms. First, ensure that the systems that Development, Test, and Operations use to manage their workflow are interoperable at least or at best there are tools out there that cater for the whole demand to delivery lifecycle - this way, Development has visibility into Test and Operations, etc. and vice versa.
It also makes sense to put testing environments in place that duplicate the conditions to be found in the production environment —such as service
virtualisation, backed by the detailed performance scenarios uncovered by data
mining the logs of the production environment.. This ensures that any testing is
more predictive of the applications real-world performance - remember our Service Management blog? Fit for purpose and fit for use are 2 different things!
Human errors cause pain and wasted time
Software release is largely a manual process in many organisations. Would it surprise you to find that most software issues are due to configuration errors? That means, there is nothing wrong with the application itself, but the software fails because it wasn’t properly configured. When configurations are done manually, it is inevitable that there will be a mistake somewhere along the way.
Errors during deployment are especially damaging because the error has the potential to be replicated across servers, desktops, and mobile devices.
what can we do?
Many organisations have attempted to solve this problem by relying on scripting. While this is certainly better than an entirely manual process, it suffers from many of the same problems because the script itself has to be built!
You need more than scripting. You need tools that automate the release of new code into production, which include documentation internally so that, especially with big teams, it actually enforces the DevOps mindset of collaboration, integration, and communication. This release automation enables you to ensure that a configuration that works properly during testing will be translated faithfully into something that will work in production. It eliminates human errors while simultaneously speeding up the whole software development lifecycle. This increases your readiness for continuous delivery, where apps are updated every few minutes, not in days, weeks, or months.
One of the biggest benefits of release automation is rollback, which allows you to return to a known good state if something goes wrong during deployment. With manual processes, and even scripting, rollback is a nightmare.
Development's job is done once the application is live
Traditionally, when the the application was handed over to production, the development team celebrated, and everybody went off to the next project.
If you are serious about DevOps, there is no better indicator of a dysfunctional process than having the development hand the application over and head off to the hills.
what can we do?
Part of what makes DevOps so powerful is that it enables you to release your applications into production on an almost continuous basis.
Instead of saving a massive list of features for a big release, the new model is to be releasing new features continuously. The introduction of the smartphone and the subsequent consumption and management of mobile applications. It has set expectations that applications will be refreshed frequently. If an application doesn’t get updated every few months with one or two new features, people wonder if the app is being properly maintained.
With continuous release, the Development team finishes one version and immediately starts on the next, adding new features based on user requirements and, ideally, guided also by feedback from Operations on how this new version is performing. Development and Operations truly are one integrated and collaborative group now.
The Blame game
If things go wrong, does this start a round of finger pointing? where everyone scrambles to show that it was someone else’s fault?
DevOps is all about collaborating and cooperating as a team, and finger-pointing is poisonous to a collaborative working environment.
This is a sign of major dysfunction. You will not be successful in implementing DevOps unless you eliminate any form of blame.
what can we do?
Finger pointing is a learned behaviour that is acquired over time. While this can be difficult to eradicate, there are ways to reduce its impact on the teams.
Make it clear that success or failure is a team effort. It takes more than one person to succeed, and it takes more than one to mess up.
Set common goals and objectives for all aspects of the development, testing, and production lifecycle. The goals should make it clear that development cannot be considered a success unless Operations also succeeds, and vice versa.
Mistakes are an opportunity to learn. You can spend time analysing what went wrong, what can be learned, what should be done differently, and whether this is a symptom of a larger problem that needs to be addressed.
Automate things to eliminate as many potential errors as possible.
This both improves process quality and enables people to focus on high value activities that really make a difference to the organisation.
Automate everything, and use analytics to track and adjust.
Conclusion
Where to start your DevOps Transformation?
Recognising that you have a problem is the first step to making meaningful change. By seeing the value that DevOps can bring to your organisation, it might now strike you that you have been overrun with dysfunctional activites without realising it.
So, how do you get out of dysfunction and get on the right track to DevOps?
From our work implementing DevOps at a wide range of different organisations, there are five things that all organisations will eventually end up doing:
Form application teams that integrate every discipline--from Dev, Testing, and Ops--together
Improve education, communications, and cross-skilling
Re-evaluate and rebuild your service delivery cycle
Evaluate new technology to support DevOps
Pick the right app or the right line of business to start with DevOps
It doesn’t really matter in what order that you do these things; the important thing is to get started!
Pick a critical application that has everyone’s attention as your starting point with DevOps. The temptation is to start small—but in DevOps, you will get the biggest payback from addressing a highly critical, highly visible application that is already causing problems. This will help alleviate much of the internal reservations about “doing things differently,” and success with DevOps will have a big impact on the organisation.
If you would like to know more about realising the benefits of the DevOps way of working or want to talk about the options of how to implement a right-sized DevOps model in your organisation, get in touch with us today!
020 3667 3666
Commentaires