The Shippable Blog

[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.

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. 

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.

Nightly builds means running an automated build for a project once a day, usually after the end of the day. It is often a good practice run automated builds every time you make some change to your codebase. These automated builds help you maintain a healthy code base.

Automated builds help in finding out a number of problems like:

• A team member checked in something that breaks the codebase.
• Your dependencies have changed and they break your code.
• Your dependencies are broken.
• Your build scripts or build machine is broken. 

Nightly builds ensures that you catch such problems within 24 hours of when they occur.