DevOps Journey: Becoming a Development Team Built for the Shift

DevOps Journey: Becoming a Development Team Built for the Shift

As the pace of business change continues to accelerate, we face increasing pressure as developers to deliver the applications and enhancements that enable our organizations to engage customers and influence their behavior – in other words, to shift and thrive. In this environment, high performance requires development teams that are built for the shift. What does this mean? In this article, I explore one characteristic that is defining high-performing development teams today: DevOps.

Understanding DevOps
Any development team should aspire to be “high performing.” High-performing teams have many advantages outside of being productive for an organization. In my experience as a consultant, they tend to have less stress, and team members have more pride in their work – which often leads to a higher quality product or output. In turn, this leads to positive relationships with clients and increases the chances of success for the overall project; whether its development or process related.

In recent years, talk of high-performing software development teams ubiquitously began to include the term “DevOps” as a guidepost for becoming a high-performing team. But what is DevOps, and why should your organization desire to understand it, beyond the idea that it is an essential component of high-performing teams?

First, according to Wikipedia, DevOps is a collection of practices that “emphasize the collaboration and communication of both software developers and information technology professionals while automating the process of software delivery and infrastructure changes.” I believe this diagram explains it best.

To go further, DevOps in the modern sense refers to automation of these processes within teams. Instead of having developers drop what they are doing, freeze the code, and do a release, high-performing teams use automation to carry out these processes. Doing so allows developers to be more productive while still maintaining quality by checking what developers are doing in parallel and carrying out processes in a consistent manner. With the extra time, developers can focus on what they are good at: developing and adding value to the organization.

A significant performance differential
In its annual State of DevOps survey from 2016, Puppet Group surveyed 4,600 technical professionals from a wide array of organizations concerning DevOps and improvements they had seen. The results were quite one-sided:

  • High-performing teams utilizing DevOps deployed code 200 times more frequently than those using standard models
  • High-performing teams saw a three-times lower change failure rate
  • And they observed 2,555-times shorter lead times

What we can glean from this is the importance of the mantra “aim small, miss small.” By focusing on shorter release cycles, teams are able to release features more quickly and more effectively, rather than waiting on a three- to six- month release cycle. Because of this, the survey found that teams spend 22 percent less time on unplanned work and rework because the shorter cycles allow them to catch changes quicker and at an earlier stage of development. Further, because of the automation and quick cycles, teams are able to integrate security validation (such as static code analysis) right into their development cycle, resulting in 50 percent less time remediating security risks versus low-performing teams.

But it goes beyond the quality aspect. As a developer, having the kind of automation I need to help keep the project on the rails is essential to my, and the team’s, mindset. So, it’s no surprise that the survey found that high performing teams using DevOps were 2.2 times more likely to view their environment as positive and seek to introduce friends as new colleagues. For our part, at West Monroe, as we have continued to adopt automated DevOps, we have seen team productivity and positive attitude flourish.

But it was not always so…

Beginning the DevOps journey
The start of our DevOps journey for our mobile team was an auspicious one. Our mobile practice leader, John Sprunger, and I had long discussed it, but we needed to find the right project on which to try it.

Our first attempt at implementing DevOps on a project involved using Visual Studio Online, similar to our web teams which use it with Azure and AWS projects for deployment. As Microsoft did not [at the time] offer managed Mac OSX instances, we had to create an on-premise Mac build agent to facilitate our iOS builds. Problems emerged almost immediately as we found the tool immature and unstable. The amount of effort required to simply configure and maintain the build environment simply wasn’t worth it, and it burned valuable hours that could have been spent on development.

Eventually, the team lost confidence in the process, and I sought to stabilize it as best I could but ultimately decided we would use Diawi for our build distribution going forward.

Enter Bitrise
Around April 2016, a colleague and I attended Xamarin Evolve in Orlando, where we were introduced to Bitrise ( I cannot describe the effect this discovery had on our DevOps efforts. Immediately, it took center stage and within a week we had our current project on Bitrise and running automated builds. The team was still wary, but that faded rapidly as Bitrise showed great stability and allowed full focus on development with little to no worry to the stability of the build server.

What made this so quick and easy was clean integration that Bitrise offered with many of the popular source control repositories and tools including HockeyApp for automated distribution and Xamarin Test Cloud for functional testing. I went from having to write Python scripts to carry out basic build tasks in VSO to dragging and dropping. And to top it off, it had managed Mac agents, so we could finally retire our build server.

In the end, the team’s efficiency soared and the developers came to rely more and more on Bitrise. This renewed the project and brought confidence to the team which contributed to turning a tough project into one of best mobile applications the team had ever created. From that point forward we found ways to extend the server and Bitrise became mandatory for all projects moving forward.

How we use it
At the core of our processes is an implementation of git-flow which emphasizes a branching structure that marks various points in the release cycle. This structure allows us to leverage the Bitrise trigger system to kick off builds based on what branch is seeing a remote push. For example, pushing to a feature branch would kick off a Continuous Integration (CI) build which ensures compilation and runs unit tests. While this is great for dev teams where we see the most value is when we HockeyApp to provide automated deployments.

These automated deployments occur when committing to branches outside develop, which in turn kick off a build script in Bitrise which will, in the end, deploy a build to the client; usually first to a QA team and then subsequently to a wider audience before being published. This allows us to gather feedback quickly and effectively and make changes as needed driven by feedback. By having these shorter release cycles and incorporating feedback faster we see better engagements with our clients and higher rates of success; truly a win-win for all.

Looking ahead
We are always looking for new ways to provide value to our clients and help improve development practices. To be successful, we make it a point to have our clients understand the way we work and how it positively contributes to their desired goals. In the case of Bitrise, we see internal client development teams using it in supporting the product once West Monroe is no longer engaged. Often this involves transferring ownership of this instance and educating their teams on proper processes; we are even seeing this as a standalone service which helps us with the goal of improving the standard of development within the tech space as a whole.

From a product standpoint, we are pleased with the success of Bitrise, but to keep up with the evolving tech landscape are always assessing new tools. Microsoft’s new product Mobile Center is an up and coming challenger, although it is still developing the level of maturity required for our larger projects; thus, we will continue using Bitrise for at least the next year.

The result: quick and fast
The previously mentioned statistics show us that DevOps is a crucial trait of high-performing and efficient teams. Having witnessed firsthand the positive impact a stable DevOps process can have, I am more convinced of it than ever. The improvement in team morale and the ability to allow developers to focus on developing cannot be underestimated.

Using DevOps allows us to shorten feedback cycles with our clients, which in turn improves relationship and builds confidence that we can deliver. We are better suited to display how Agile and DevOps together, result in achieving the value they seek. DevOps is a huge enabler of the core tenant of: be quick and fast. The very idea behind Scrum and related methodologies is to create small iterations, gather feedback, adjust, and iterate again. The idea behind good DevOps is to allow for review of iterations as often and quickly as possible. It’s fair to say that we need good DevOps to have good Agile. And here, at mezzo of our journey, we are seeing these benefits first hand.

Interested in getting going in DevOps? We’re happy to share our experience and to help you think about ways to improve the performance of your development teams through DevOps best practices. Contact Jason Farrell or John Sprunger via the comments box. 

Phone: 312-602-4000
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons