The Shippable Blog

Why DevOps Efforts Fail

[This article was originally published on SDTimes as a contributed article.]

The main goal of DevOps is simple: ship software updates frequently, reliably, and with better quality. This goal is somewhat 'motherhood and apple pie', and every organization will agree that they want to get there. Many will tell you they've already embarked on the DevOps journey by following some commonly followed frameworks, such as CALMS

However, very few will express satisfaction with the results. After speaking to 200+ DevOps professionals at various stages of the adoption lifecycle, we found that organizations generally fall in one of 3 categories:

We were most interested in groups 2 and 3 since they were actually in the middle of their DevOps journey. When asked to better explain the challenges and roadblocks, here is what we found:

  • 68% said the lack of connectivity between the various DevOps tools in their toolchain was a very frustrating aspect.
  • 52% said a large portion of their testing was still manual, slowing them down 
  • 38% had a mix of legacy and modern applications, i.e. brownfield environments. This created complexity in terms of deployment strategies and endpoints, toolchain, etc.
  • 27% were still struggling with silo'ed teams that could not collaborate as expected
  • 23% had limited access to self-service infrastructure.
  • Other notable pain points included finding the right DevOps skillset, difficulty managing the complexity of multiple services and environments, lack of urgency/budget, and limited support from executive leadership.

Let us look at each of these challenges in greater detail.

4 Trends Driving DevOps Adoption

There has been a tectonic shift in the way we build, deploy and run applications. What started with cloud infrastructure has now created a revolution in IT organizations. As organizations realized the importance of continuous feedback loops, it created a need to ship software updates as fast as possible and brought in a culture of collaboration where everyone works as a team and not as a member of a silo.

This is fundamentally due to the DevOps movement. The word itself derives from “Development” and “Operations” and is all about removing barriers between Software Developers and Operations engineers and enabling better collaboration between the two. It also focuses on automation as the primary way to make software delivery lean and measurable.

DevOps is gaining rapid adoption due to some macro trends in the software universe: 

  1. Software Defined Hybrid Cloud
  2. Web-scale Requirements
  3. Modern application architectures (micro services, functions) 
  4. Containers 

The Future Of DevOps Is Assembly Lines

Last week, we announced the General Availability of Shippable Server, the behind-the-firewall version of our hosted platform. We also articulated our vision around where DevOps is today and why Assembly Lines is the future of DevOps.  

As I think about our journey from CI to Assembly Lines, it mirrors the journey of most organizations as they mature their DevOps efforts. In a nutshell, DevOps has created an awareness of the need to automate and be more efficient in terms of software delivery. However, most of the focus around the how has been around cultural changes and tools that help automate bits and pieces of the end-to-end software delivery workflow. This has led to the formation of "islands of automation" that are optimized for specific tasks but do not enable the holy grail of Continuous Delivery or Continuous Deployment. To achieve those goals, you need an Assembly Line platform that takes all these tools and connects them into end-to-end workflows with complete visibility, traceability, and auditability.

So let's take a look at this journey, and dig in a bit deeper into why Assembly Lines are the essential factor to DevOps success. 

Build, test and deploy applications independently from a monorepo

In our previous blog posts, Our journey to microservices: mono repo vs multiple repositories, we shared our thoughts and experiences on our approach with monorepo. We received a few questions after that blog on how CI and deploys go with the monorepo.

In this article we will learn how to run CI, build and deploy applications independently from a monorepo. On each PR/commit we will run tests on the service which has changed build a docker image from it and push it to a registry. This image can then be deployed to to a cluster on any supported Container ServiceWe will use Shippable for this scenario.

How to build, deploy and test applications with Shippable pipelines.

When appropriate tools & technology are available in abundance, automation is considered the primary resource to improve the efficiency of any software development process. Faster innovation cycles and speed to market are crucial to a business. With the very same principle in mind Shippable was founded so that software powered organizations could accelerate innovation. Shippable provides an integrated platform, using which you can automate your software delivery from source control to production, without needing to write complex, imperative code.

In this tutorial we will learn how to create an end to end deployment for a single service, with source code maintained in a repository on github. We will also see how to trigger tests every time the deployed environment is updated or your test cases are updated.