DevOps has evolved into a global movement, yet it is a term that still generates confusion. Many organisations are aware of their need to enable more efficient delivery. Everyone recognises the existing points of failure, but when it comes to deal with them very little action is taken within the organisation.If you are new to DevOps, I recommend checking out our first article: what is DevOps.

This article will address DevOps from a practical approach according to the most common problems I’ve found in organisations.

My experience

Any IT transformation consultant will tell you there are a set of patterns that tend to get repeated in every company, therefore forcing the same problems to appear. From a DevOps perspective, that is absolutely true. The concept of DevOps covers a wide range of activities directly or indirectly related to the software delivery lifecycle (SDLC), which, in its nature, encounters multiple problems often easy to foresee.

Communication and collaboration are absolutely essential to keep processes in order and work as a whole. What happens is that teams tend to fall into the habit of repeating the same actions all over again, even when it is commonly known that issues are there.

As an IT consultant, I’ve had the chance to experience how silos are created within a company. It is interesting how open people are when having a conversation with an external consultant. Everyone acknowledges the issues, many know the causes which frequently point to the lack of cooperation between teams. A few even know how these would get solved, yet the organisation lacks initiative to push things through. The DevOps “philosophy” can help.

Most common challenges

Deployments taking too long

Distributed applications often require more than ‘copying and pasting’ files to a server. The complexity increases when having a farm of servers. Uncertainty about what to deploy, where, and how, is a normal thing. The result? Long waiting times to get our artefacts into the next environment of the route to live delaying everything, testing, time to live, etc.

What does DevOps bring to the table? Development and IT operations defining a deployment process in a “blameless” collaboration session, verifying what works and then taking it to the next level with automation to facilitate continuous delivery. This dramatically cuts timing for deployment; it also paves the way for more frequent deployments.

Missing artefacts, scripts and other dependencies

Closely related to the previous point. We frequently encounter failures recently after a new version of a working piece of software is deployed, often caused by missing libraries or database scripts not being updated. This is caused by a lack of clarity about which dependencies to deploy and their location. Again, fostering collaboration between development and operations can resolve these sorts of problems in the majority of cases.

When it comes to automation, dependencies can be defined which helps a great deal in speeding up deployments. Configuration management tools like Puppet or Chef contributes with an extra level of definition of dependencies; we can define not only dependencies within our application but also at infrastructure and server configuration level. For example, we can create a virtual machine for test, and install/configure tomcat before our artefacts are published.

Confusion about what to test

Testers also get their fair share of confusion as the functionality deployed is not clear or not shared in a common backlog, the QA team does not know what exactly they have to test. Obviously when that happens untested functionality goes through the route to live until production, therefore exposing systems to unpredictable errors.

When the QA team is included in daily stand-ups and/or planning sessions predictability increases, it allows the team to prepare user cases and distribute the work before hand. Furthermore, having multi-team stand-ups promotes development-testing collaboration and provides a daily platform for the QA team to ask operations questions about the development work.

Slow test processes

Many defined use cases are executed manually all over again; some of them are long and laborious but composed of multiple simple steps with zero challenges. Those activities consume man hours, preventing the QA team to focus on more innovative tasks.

Under an ideal DevOps landscape those repetitive use cases can be automated. Adoption of test automation tools like Selenium, Rally or HP QT free up the QA team for other critical activities.

Unavailability of environments

For those with development background, how many times did you deploy a test environment, only to find out that it fails? Downtime is a frequent issue; again IT operations cannot foresee or plan in advance if communication with development is low or inexistent.

Simply by the fact of bringing development and operations together to define processes and needs will translate into notorious results. Defining a clear process and configuration elements and then adopting configuration management tools such as Puppet, Chef and Ansible is a good strategy to aim for. The beauty is that you can automate the creation of a virtual machine (either in-house or cloud-based) before deploying, then configure that virtual machine, then deploy your artefacts, and finally, run a set of automated tests.

Ineffective production monitoring

Sometimes monitoring tools are configured in a way that produce a lot of irrelevant data from production, however, other times they don’t produce enough or nothing at all. There isn’t any definition of what needs to be looked after and what the metrics are.
Agree on what to monitor and which information to produce, and then put controls in place. Application Performance management tools are a great help if your organisation can afford it take a look to AppDynamics, New Relic and AWS X-Ray.

Firefighting instead of innovation

One common scenario is spending most of the time in ad-hoc repetitive tasks or solving emergency issues. Hence, the team is left with no time to innovate and create, and, over the years turns your IT system into a legacy monolithic system. I suggest doing some reading on IT bimodal organisation.

Adopting DevOps practises and technologies certainly requires investment of time and money; there is a learning curve which many organisations are reluctant to assume. Once that barrier is overcome the advantages outweigh the disadvantages. I found that those organisations who carve out some room in the budget to bring external consultancy will normally get the investment back. Getting to build a DevOps pilot is a great first goal.

High dependency on specific individuals

There are always a few individuals more talented or dedicated than the rest, those who seem to know everything about new technologies or who writes “magical” scripts to solve a specific issue quickly. The problem is that these people adopt the problem as their own problem instead of escalating it to a team level. Usually, they do so to avoid bureaucracy in companies that are not open to explore alternative solutions or technologies.

Invest some time for innovation, let your development and operation teams investigate and come up with new solutions. You can do that by assigning specific individuals and separating them from the daily tasks, or rotating that role to motivate the team. Listen to their proposals, and, as a team, consider the benefits.

Conclusion

Achieving a fully operating DevOps landscape won’t happen overnight. There are many changes to address in terms of mindset, definition of processes, and technologies. Split your goals into quick wins, medium term and long term, define your success criteria for the future compared to where you are now. Approach the journey with baby steps, it takes less time than you expect to reap the benefits.