devopsy.kinsta.cloud

Tag: continuous delivery

Welcome to the Continuous Delivery 101 Podcast

No matter what industry you’re in or how old your business is, your software often determines your success in today’s application economy.

Applications are the face of your business—both the way it performs and the speed with which you can incorporate new ideas and innovations, driven by the efficiency of your software development life cycle—determines whether your company can survive in this competitive market.

Software doesn’t just support the business today, it drives the business—and your organization’s livelihood in this application economy comes down to your ability to quickly deliver world-class capabilities. As a result, more organizations than ever are turning to the practice of continuous delivery (CD) to improve their ability to plan, build, test and release applications to market.

With this increased focus on continuous delivery methodologies and practices, we’ve established a new podcast that highlights the importance of utilizing CD, along with adoption techniques and other best practices.

Dubbed “Continuous Delivery 101,” the series features some of today’s leading experts in the field discussing where they’ve seen CD success, across some of the world’s top organizations and across multiple industries.

The first episode in this series covers CD fundamentals and the software evolution that has made continuous delivery so critically important.

Beginning in the ‘60s, this first wave of this software evolution saw mainframe systems brought in to automate business tasks. A second wave saw the emergence of ERP/CRM-based processes, so we could improve how we run contact management and transaction processes. Today we’re in the third wave, which started with the widespread adoption of mobile and web technologies, with all of these paradigms intersecting in perfect convergence.

Businesses that have mainframe and distributed systems, that have CRM and ERP system, that have web fronts and mobile apps, are utilizing these continuous delivery tools to innovate faster than ever before. These organizations are being forced to reinvent how they communicate with customers and how they deliver goods and services to stay relevant in the market. This third wave, where business is now driven by IT, is the biggest disruption that we’ve seen.

To hear a lot more on this topic, check out the first episode of the Continuous Delivery 101 podcast via YouTube or the iTunes store, where you can find it on the Podcast App by searching for “Continuous Delivery 101 podcast.”

Software delivery, fueled by CD, is evolving at a furious pace. Stay tuned for more expertise and best practices.

— Scott Edwards

January 18, 2017
Predictable Progress: Tracking DevOps Maturity Metrics
As DevOps methodologies continue to evolve, we’re naturally seeing an increased emphasis on the cultivation of related maturity metrics.

For instance, in the 2016 State of DevOps Report, researchers with DORA took an initial stab at creating relevant ROI measurements.

Similarly, a new report issued by researchers Coleman Parkes, sponsored by CA Technologies, offers additional evidence that as agile and DevOps processes continue to expand, today’s practitioners are increasingly employing metrics to optimize their efforts.

The report, titled, “Accelerating Velocity and Customer Value with Agile and DevOps,” finds some form of adoption among nearly every enterprise, with 87 percent having adopted agile to some degree and 73 percent leveraging DevOps.

Related to the overall maturity of these practices, those organizations that are moving to embrace the techniques most broadly are predictably seeing greater returns. Yet, despite the widespread adoption, only a third have deployed either practice widely, according to the research.

Percentage of Advanced Adopters Reporting Improvements in Customer Experience

Based on a survey of 1,770 senior business and IT executives, the study also closely investigates the specific KPIs that organizations are using to gauge how agile and DevOps initiatives are translating into customer interactions.

Most notably, “advanced” agile and DevOps adopters have observed more than an 87 percent improvement in overall customer experience, compared to “basic” adopters.

In terms of how those efforts are affecting business drivers, Coleman Parkes finds:
- Advanced agile practitioners are experiencing a 40 percent improvement in time-to-decision, compared to 33 percent for basic users.
- Advanced DevOps adopters have noted a 42 percent improvement in speed-to-market, compared to only 24 percent for basic practitioners.
Key Performance-Invoking Indicators

To that end, the research highlights specific KPIs that organizations are using to measure the impact the agile and DevOps practices are having on customers. In fact, the study finds that between two thirds and three quarters of all the organizations surveyed have established such measurements.

At least half of these focus on business or customer-related metrics, reflecting how “critical software has become to businesses’ ability to achieve their core mission,” Coleman Parkes researchers note.

Among the mostly widely invoked metrics, include:
- Business growth (specifically revenue): over 73 percent
- Operational or process efficiency: over 73 percent
- Employee productivity: over 73 percent
- Customer experience: over 71 percent
- IT-related costs: over 71 percent
- Speed-to-market: over 71 percent
- Customer satisfaction (via NPS): over 70 percent
- Time-to-decision: over 70 percent
- Quality of development: over 70 percent
- Employee retention: over 64 percent
If increasing applications delivery speed and overall organizational velocity are, in fact, the primary goals of engaging agile and DevOps, the research bears out that the techniques are having the desired effect. After all, the survey finds that time-to-decision and speed-to-market are being accelerated among approximately a third of the organizations studied.

Related to other notable KPIs, Coleman Parkes highlights that a full three-quarters of adopters have moved the needle on overall customer experience, along with employee recruitment and retention, a significant benefit that was also highlighted in the State of DevOps Report.

Along with positively impacting customers, the reality is clearly that agile and DevOps are also making a big difference in allowing companies to improve the atmosphere for their workers—a huge benefit when you consider the shortage of talent in IT today, and how much it typically costs to attract new employees, just as DORA’s researchers noted.

Other key findings by Coleman Parkes include “before and after” metrics that many organizations are observing related to their continued adoption and advancement of the involved methodologies themselves.

I encourage you to download the entire report, and leverage it to measure how far you’ve come with Agile and DevOps transformation—and where you may need to re-examine your efforts.

— Aruna Ravichandran
January 16, 2017
How Open Source Can Help Your CD Chain
What can you do to make continuous delivery work better? Consider moving to open source software solutions. Here’s why.

Many DevOps teams already may be using open-source platforms for reasons not related to continuous delivery. They might like the cost-efficiency or interoperability that usually come with open source. Or maybe they just like the open-source philosophy.

Typically, however, open source is not viewed as a requirement for doing DevOps or achieving continuous delivery.

How Open Source Speeds Continuous Delivery

But maybe it should be. Consider the following ways in which open-source code can better facilitate a continuous delivery pipeline:
- It’s easy to tweak. Because anyone can view and modify the source code of an open-source program, you can change it to work as efficiently as possible. Custom enhancements could make the open-source tools you use work more efficiently within your delivery chain.
- No vendor lock-in. Most open-source tools and platforms are designed based on open standards. The threat of vendor lock-in is minimal. For that reason, adopting open source helps prevent surprises that could otherwise hold up your continuous delivery pipeline in the event that a vendor decided to stop supporting the tools you are using.
- It’s well-known. Mainstream open-source tools are widely used. Chances are good that the people who are currently on your team, or will join it in the future, already know open-source tools. That’s an advantage for continuous delivery because it means you won’t have to spend time training staff—and risk introducing delays to your continuous delivery chain while the staff are being brought up to speed.
- It gives you options. With open source, you usually have lots of implementation options. Want to deploy on Linux? There are about a dozen mainstream distributions you can choose. Want to run your cloud with OpenStack? There are lots of distributions of that, too. Having choice is a good thing for continuous delivery because it allows you to switch easily between different frameworks or tool implementations as your needs change. That agility prevents you from being locked into a specific solution.
This is not to say that open source is a silver bullet. Achieving continuous delivery requires attention a lot of other factors; it’s not as simple as using a certain type of technology (if it were, everyone would be delivering continuously). But adopting open-source solutions when possible certainly can’t hurt—and it just might help as you seek to deliver software continuously.

— Chris Tozzi
January 13, 2017
DevOps by the Book in 2017: Where we Really Stand

Now that the year-end prediction season is over, it’s time to focus squarely on the actual here and now—where the DevOps movement actually stands at the start of 2017.

As we’ll need to wait another six months or so for the annual State of DevOps Report to emerge from the good folks over at DORA and IT Revolution, which forces us to take stock of the situation using other resources. In this case, I’ll point to the recently released book, “DevOps for Digital Leaders,” authored by my colleague Aruna Ravichandran along with co-authors Kieran Taylor and Peter Waterhouse.

Register today for the upcoming webcast, “Chart a Winning Course: DevOps for Digital Leaders,” and enter the chance to win a free signed copy of the book [U.S. only].

Why should you value this book over any of the other DevOps-related titles inundating the technology literature scene, in particular those issued by (gasp!) technology vendors? I’d cite two very specific reasons: real-world metrics and use cases.

I often preview any comments I make in cross-functional meetings with the phrase “shameless marketing.” That is because I work in marketing. For 12-plus years prior and sometimes in between marketing gigs I’ve served as a journalist, wherein my job was to attempt to be as objective as possible. Today, I work for a vendor that would really like to sell you stuff.

That said, this current career path does not preclude me from being able to see beyond my own not-so-secret agenda. While many onlookers understandably groan and roll their eyes at the manner in which DevOps has been co-opted by marketers as a means to advance products, this doesn’t mean we’re all full of it.

Like myself, working at CA—in particular, leading marketing efforts that span a huge array of strategic technologies actively being leveraged by global enterprises to attack various elements of DevOps—has given Aruna and her partners tremendous insight into where many people stand in terms of maturity.

To that end, this book is written around some fantastic stories about how some of these organizations are refining best practices and measuring real success in domains including continuous testing, release automation and shift-left monitoring. IMHO, these are some of the hottest areas of DevOps being advanced as we speak.

In addition to these use cases and related practices, the book takes an up-close look at critical aspects of the DevOps build, test, deploy and manage stages, along with key processes related to tuning and continuous improvement. And it even goes so far as to talk about essential DevOps tooling. I hope people are ready to acknowledge that beyond culture and leadership, automation absolutely plays a significant role in all of this.

Specific to metrics, one of the areas where the State of DevOps peeps attempted to break new ground in the 2016 report, there’s a lot to appreciate. The book takes a close look at how these same organizations are attempting to tie DevOps-driven change directly to ROI, including the all-important customer experience.

Worth noting, in the coming days we’ll also see the release of a new report from Coleman Parkes that charts numerous KPIs being used to this same end, so stay tuned.

So there you have it, the marketer has officially hijacked this blog space to do little more than market a book about DevOps written by marketers. But, the truth is that’s not all.

If you really want to hear the best parts of this story, sign up for the upcoming devopsy.kinsta.cloud webcast, “Chart a Winning Course: DevOps for Digital Leaders,” in which Aruna and Alan Shimel will discuss the high points, with an emphasis on fielding questions from the audience live Q&A style.

If you don’t have time to read the book—or, better yet, you want a preview to ensure that what I’ve written here is true—post up and ask your own questions. We’ll also be conducting live polls about DevOps maturity, audience use cases and the leading types of DevOps metrics.

It’s worth noting that all proceeds from the print edition will go to Foundation for Excellence, which provides STEM scholarships to children in India. Order your own copy today (or download it for free).

— Matt Hines

January 12, 2017
DevOps Leaders Share 2017 Reflections, Predictions
As the New Year kicks off, it is a time for reflection and a chance to look ahead and plan for what is to come. While many are making personal resolutions pertaining to their physique, job performance or travel plans, there is a lot of chatter in the software delivery space around what DevOps will look like these next 12 months.

Looking back on 2016, suffice to say it was a big year for DevOps. There was no lack of resources for those in any phase of a transformation, with global conferences touting its name to weekly (if not daily) podcasts and webinars designed to share the latest expertise with the community. However, as DevOps moves from buzzword to phenomenon, it will be held to even higher standards and scrutiny, becoming ever-more polished and perfected as challenges are faced and overcome. But don’t just take my word for it.

Electric Cloud recently hosted a live, online video podcast featuring notable DevOps luminaries discussing their own reflections and conjectures. The panel included Nicole Forsgren, CEO and chief scientist at DORA; Robert Stroud, principal analyst at Forrester; Chris Riley, analyst at fixate.io; Manuel Pais, author at InfoQ and SkeltonThatcher; Alan Shimel, editor in chief at devopsy.kinsta.cloud; Sam Fell, VP of Marketing at Electric Cloud; and yours truly. This article highlights 16 different insights from our discussion with these great minds in DevOps. Here’s to what has been, and what is to come!
- Expect to see a trend toward strategic DevOps transformations in 2017, according to Forsgren: “I think there’s going to be a huge trend moving forward to do really careful and strategic assessments about where you are, intentional prioritization and strategy about understanding what your constraints are, so that you can do strategic capabilities development moving forward.”
- Riley hopes 2017 will be the year we stop talking about DevOps and start doing it: “In 2017, we’re going to stop defining DevOps, and we’re going to hopefully use the word a lot less. We’re going to be real about what it is and getting it done. It’s going to be a lot less talk and more doing.”
- I emphasized that having good architecture in place is crucial to successful DevOps: “What’s starting to happen is that you’re going to have a really hard time doing DevOps well with a crappy architecture, whether that be a crappy architecture for your pipeline or crappy architecture for your application. Application architecture matters in your ability to do DevOps well.”
- Stroud emphasizes the importance of experimentation in DevOps: “Organizations [will] look to drive mainframe R&D in a DevOps methodology—not just mainframe development, but also supporting velocity in rolling it out to production, with organizations moving from one or two major releases a year, to now experimenting with both quarterly and monthly releases using DevOps practices and experimentation and techniques.”
- While tools and processes play a major role in a DevOps transformation, we must not forget to maintain a culture of empathy, emphasizes Shimel: “Have empathy for your fellow workers, empathy for your fellow humans. Don’t think because you’re the dev, that what you’re doing is more important than what the ops guy is doing.”
- DevOps certifications are the future, according to Pais: “I think we’re seeing more and more DevOps education and certifications. I know, for example, there’s an IEEE standard for DevOps being worked on.”
- Sweat the small stuff, advises Fell: “It’s never been truer than in this accelerated cycle that we’re seeing with productivity and all this awesome value being created from relatively minor, incremental improvements in process, in tooling, and all the stuff that we do, and the feedback that we’re getting.”
- I believe 2017 will bring major disruption in the FinServ community: “We will see some, hopefully, interesting disruption in the financial technology area, because the financial institutions have always treated technology as a key differentiator. Now, the problem they have is that their culture, by and large, sucks.”
- Some wise words from Stroud: “Strategy without execution is wasted time. We have to execute. We have to be prepared to fail. We have to be prepared to come and share our experiences.”
- Measure, measure, measure is Forsgren’s DevOps focus in 2017: “What’s going to be my goal is having all of us think about measuring in smart ways, so that we can actually do these experiments that are small, that allow us to fail, because big massive failures are scary, but those are the ones that are easy to measure with crap measurements. Because when you fail big, you know you failed big.”
- In 2017, we will see a breakdown of DevOps tools’ silos, per Shimel: “It’s really ironic that in something like DevOps, where the idea was to break down silos between dev and ops, dev and QA, and QA and security, but what we’ve done is we’ve built new silos of DevOps tools.”
- Pais on the trends he sees in early adopters of DevOps: “For the majority of organizations that have already been doing DevOps for a while, they’re now focusing on what’s the best way to organize teams. Moving, often, from having just specific people who know about continuous delivery, DevOps and so on, to actually getting platform teams that embed all the services that they want the development teams to use.”
- Oddly enough, development teams are still more likely to adopt DevOps than operations teams, explains Stroud: “One of the data stats we pulled has to do with DevOps adoption in development versus operations. Isn’t that ironic? Because the name DevOps is dev and ops. We still see significantly more DevOps adoption in development than operations, but the good news is the gap is closing, based on the Forrester data.”
- Containers will continue to be a major player in 2017, says Riley: “Where I believe there will continue to be growth is container-native tooling, container-native security and container-native release automation.”
- The reality is, there are still a lot of organizations not doing DevOps, remarks Fell: “We are living in this bubble, happy bubble, of everybody gets DevOps and we’re all Agile. But we talk with folks that we talk to who are just like, ‘Yeah, we do nightly builds, and we’re really looking forward to doing continuous integration.’ Your jaw drops, like, ‘Wow. Yeah, that’s a good idea. You should do that.’”
- And, finally, I share some sage wisdom to keep in the back of our minds: “If what you’re doing on any given day isn’t moving that ball forward, what is the point? I think we need to focus a little more on that.”
Bonus 17^th quote for 2017, from Shimel: “I think the story of 2016 is DevOps has gone mainstream. We’re seeing pockets of DevOps come together as bubbles, but we still have the majorities in front of us, going forward.”

For more reflections and predictions, watch the full episode:

About the Author/Anders Wallgren

Anders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings with him more than 15 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products. Anders holds a B.SC from MIT. Connect with Anders on LinkedIn or Twitter.
January 10, 2017
15 DevOps Expert Opinions on Continuous Integration and Delivery

We at Shippable recently approached some DevOps experts and asked them what they really think about continuous integration (CI) and continuous delivery (CD). The responses were just amazing, proving that CI/CD’s future is just bright and long in the software development process.

Perhaps this insight might be of help to organizations, regardless of whether they already practicing CI/CD or have yet to adopt it in their organization.

Sit back, relax and read these opinions from DevOps Experts:

1. Chris Nwamba

Chris Nwamba is a self-described code beast who works with scotch.io. “Continuous integration is simply ‘building big and shipping small,’” he said. “The developer or engineer is not expected to produce a complete result; the project is divided into milestones and he or she can produce the expected output for each milestone which is reviewed and pushed. Continuous delivery, on the other hand, involves delivering and deploying a tested and usable feature to the end user as soon as it is available from the engineer. No constraints such as milestones or daily reports are placed on the engineer; rather, the product is delivered when it is ready and tested within a reasonable amount of time.”

2. David Bernstein

David Bernstein is the author of “Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.” He says, “I’ve written a lot about CI and CD. It’s one of the nine core practices in my new book. The first principle of the Agile Manifesto is, ‘Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.’ The practice of continuous delivery is the only way I know to achieve this principle and is at the very core of Agile software development.”

3. Tomohiro Iizuka

Tomohiro Iizuka is a full-stack web application developer. He says, “Continuous integration and delivery are still at the frontier of IT technology, like NoSQL. It will change the business style of freelance engineers. Businesses using cloud servers will especially change. However, there are some issues to solve in order to execute it. An IT system consists of some subsystems that affect how teams work together on development and management after the first release. If an engineer can provide a subsystem that’s comprehensive to end users, freelance engineers can have their own product and they can concentrate on maintaining their own product continuously. That will make use of cloud platforms more popular, and they can have opportunities to gain profit continuously in addition to development fees. Open-source products like Eclipse, Firefox, WordPress are some examples. However, in general, that is not done. I think that the platform for making independent software components is necessary for freelance engineers to make new businesses with continuous integration and delivery.”

4. Anubhava Srivastava

DevOps expert Anubhava Srivastava is a lead engineer-architect at AOL Inc. According to him, some of the advantages of CI and CD are: “DevOps and CI/CD give more power to developers. Developers have greater control over the application stack and require access to production servers. The exact same repeatable deployment process is used across different environments like dev, QA, staging and production. Everything is automated right after code is checked in. There’s fast and quick resolution time for emergencies. Due to code coverage reports being monitored and shared widely, developers are forced to write test cases for every line and every condition in the code. Due to stress on TDD, developers are producing higher-quality applications with significantly fewer bugs. It has definitely helped the organization, as they don’t need the same headcount for QA and Ops teams anymore.”

5. Erik Dietrich

Erik Dietrich is the founder and principal of DaedTech, LLC. He says, “In short, both of those [CI and CD] are practices that I endorse and help people move towards. On the whole, I’m a huge fan of automating the automatable to avoid mistakes and save time.”

6. Tom Zorde

Tom Zorde is an enterprise architect at Monadelphous. He says, “There is an inevitable need for CI, no doubt. But developers need to have autonomy to self-elect to skip a check-in if they don’t feel their code contribution is ready. This will reduce the wasted effort of dealing with failed integrations and keep developers focus in the zone.”

7. Ian Robertson

Ian Robertson is a product owner at River Island. He says, “I work in retail (fast fashion). While we do build core ranges to meet the seasons, it is our quick response to rapidly changing trends that generates the excitement that drives our brand values. An emerging style cue seen on the catwalks one Friday can be in our stores and online by the following weekend. Those same customers expecting the latest fashion will be interacting on our app and website, so we need to be as Agile in development and deployment as we are in apparel design and production to keep up with customer expectations. It’s not just the front end; our supply chain, logistics and merchandising systems need to be able to respond rapidly to real-world changes. Adopting CI and CD allows us to reduce the time to market, reduce risk, deliver better customer experiences and drive value for the business.”

8. The Folks at Browser Up

Browser Up is a performance and load testing tool. Folks there say, “Using CI and CD is a force multiplier that amplifies the speed at which software can be developed and delivered. To be effective, a CI and CD pipeline must include a robust test suite that include continual performance and functional testing.”

9. Georg von Sperling

Georg von Sperling is a practitioner, evangelist and general geek on software development methodologies, technology, patterns, systems, delivery practices and DevOps. He says, “CI and continuous deployment are very technical in nature and benefit the technical teams. They are crucial to address. They do not, however, define continuous delivery. CI could be defined as an early detection system at the code and build level. Early detection at those levels have been proven beneficial as these are types of bugs that are exponentially more costly to remediate at later stages. Continuous deployment is an ability to promote code technically down the pipe into production at velocity, allowing consumption faster. There are facets of continuous deployment that must be considered: rollback, A/B testing and metrics gathering. Many fail here very quickly. Continuous delivery (of which I am an avid advocate for) is a business subject; although, in software powered organizations and/or digital business models, it has a fairly large technical component. It is very difficult, if not impossible, to translate CI and continuous deployment into direct business benefits. Continuous delivery, however, is business metrics-driven and defensible at the CxO level to stakeholders and shareholders.”

10. Endi Sukaj

Endi Sukaj is a full-stack developer who specializes in back-end development. He’s currently a community team member at Slant.co. He says, “CI is a crucial part in the development and deployment process of projects of a certain size especially if two or more people are working on it. The most valuable resource is time, and a good CI service and implementation helps developers in saving as much time as possible by avoiding ‘integration hell’ and by running all unit tests in the same environment as in production.”

11. Jordi Mozcode

Jordi Mozcode is a software developer focused on .NET Core, MVC, TDD, SOLID, clean, software quality, best practices, secure coding and pentesting. He says, “In my professional experience, the adoption of continuous integration and continuous delivery improves three basic facts: quality, flexibility, and speed. Quality, because CI guarantees a much lower rate of development bugs and CD provides a robust and secure system throughout the development cycle. Flexibility, because at every step of the development cycle you have the control of continue to next step or going backward easily. Speed, because in an idyllic case with no development bugs the release can be deployed in production almost instantly.”

12. Dave Kerr

Dave Kerr is a software developer for everything from device drivers to full enterprise applications. He says, “If the org is building tech services or products, CI and CD are critical. Deployment doesn’t need to be continuous but the team needs to be confident that what they are building is shippable.”

13. Matt Kurleto

Matt Kurelto is a serial entrepreneur and CEO at Neoteric. He says, “I think it’s a necessity if you are thinking seriously about cloud services. I think that microservices architecture can only be well-leveraged with automated CI, CD and QA flow, and for me, this setup is a must if you want to take advantage of lean business and agile project management.”

14. Sean Handley

Sean Handley is the lead cloud applications engineer at DataCentred. He says, “CI and CD are things we practice on our tech team. They allow us to ship production changes many times per day in confidence. My view is that any software team not using CI and CD needs to seriously reconsider their methods!”

15. Manisha Sahasrabudhe

DevOps Expert Manisha Sahasrabudhe is the co-founder at CMO at Shippable. She says, “All companies are software companies today, and faster innovation is the key to winning against your competitors. Continuous integration and delivery are crucial in helping you accelerate your release cycles and innovate faster than anyone else. This will become especially important as microservices become ubiquitous and your application is composed of hundreds of services that need to be deployed, scaled and monitored independently. CI and CD automation is the only way to bring some method to the madness.”

We hope these DevOps Experts opinions are enough for you to figure out how important it is to adopt to CI/CD practices.

— TeamShippable

January 4, 2017
Are You Paying a ‘Wait-Time Tax’ on Your Global DevOps?
Business increasingly is global, so DevOps has become global as well. In fact, for many enterprises, DevOps entails collaboration between development, test/QA and ops teams across multiple continents.

This is in part due to the economics of IT labor and in part because applications for global enterprises have to be deployed globally.

Unfortunately, enterprises executing DevOps globally must confront the physical realities of global code distribution. And those physical realities impose a “wait-time tax” that fatally undermines Agile processes and culture.

But they don’t have to. There’s a tax-free way to share large volumes of code across globally dispersed DevOps teams.

The Wait of the World

Every time you ship a massive build worldwide, you have to wait. Assume, for example, that you’re sending a 10GB build to five different locations over a 10Mbps MPLS connection. If a couple of your remote locations have 5Mbps connections, it will take them five hours to get each build. But if you have three locations with only 2Mbps connections (as is likely the case in Asia), they will have to wait 12.5 hours.

That wasn’t a problem when you iterated your builds with limited frequency. But as you try to become more aggressive about highly iterative Agile development and testing, this “time tax” becomes punishing.

For one thing, you lose productivity as your overseas developers and test teams wait idly for new artifacts. And these chronic wait times fundamentally undermine the Agile culture you’re trying so hard to build across your organization.

In fact, if your current model for distributing code globally remains as-is, you’ll never achieve the speed and iterative frequency your business needs. And you’ll certainly never come anywhere close to continuous delivery.

Faster Cycles from Dublin to Dubai

Fortunately, you can eliminate DevOps wait times, regardless of how globally dispersed your teams are and how thin their connections to your enterprise network may be.

The solution entails a hub-and-spoke model that:
- Lets you maintain a “gold copy” of your current codebase(s) in the cloud;
- Provides all your remote locations with their own local codebase copies that get continuously and automatically updated with any incremental changes as they occur; and
- Leverages each location’s high-throughput internet connection.
The combination of small, incremental code updates and high internet bandwidth dramatically changes the rules of the global DevOps game, allowing even the most geographically dispersed teams to work with even the largest codebases extremely iteratively and without delay.

It’s difficult enough to sync dev and test teams on different continents. And the pressures on your organization to respond immediately to ever-changing market and regulatory demands will only intensify. So now’s the time to consider abandoning your obsolete approach to global code distribution and adopt a model that better enables you to be fast, super-iterative and global.

— Barry Phillips
January 3, 2017
Closing the Gap on Continuous Delivery Metrics that Matter
Management guru Peter Drucker once said, “If you can’t measure it, you can’t improve it.” I would take a step back and say, If you can’t measure it, you can’t get it off the ground. Many companies that I work with are amid digital transformation initiatives, such as the adoption of DevOps and continuous delivery. For these initiatives to gain momentum and acceptance within their organizations, they must be able to demonstrate quick time to value or risk being sidelined. And then, these organizations must be able to actualize their transformations and improve their processes—both enabled by the right metrics.

Indeed, one of the core pillars of DevOps culture—going all the way back to the first DevOpsDays event in 2010—is measurement. It is the M in the CAMS (Culture, Automation, Measurement, Sharing) acronym coined by Damon Edwards and John Willis.

Glaring Gap in Continuous Delivery Metric Definitions

Despite the prominent placement of measurement in the DevOps world, there is not really a lot of guidance about metrics in the common literature. For example, the original “Continuous Delivery” book by Jez Humble and David Farley devotes maybe a dozen pages out of 500 to it. And the recent “DevOps Handbook” by Gene Kim, et al is thin on the topic as well.

The coverage gap around measurement and metrics is driven primarily by the fact that the DevOps space is new and there are few standards around which to build an easily documented metrics structure. That leaves practitioners with the challenge of creating something they can use pragmatically within their own organizations. Anyone building a system of measurement for their organization must have a reasonable understanding of metrics as a discipline and a good understanding of the processes they intend to measure.

Back to Basics on Measurement

There are two types of metrics that I discussed in a recent session at CA World ’16 that are important when measuring a complex enterprise process.
- Result metrics are concerned with the cumulative outcome of a set of activities. For example, a company’s revenue or net income would be common, classic result metrics.
- Performance metrics measure how well individual activities are working. These often are more difficult to define, as they can vary by businesses and teams and be obscured by silos.
Performance and result metrics are very closely linked: Performance metrics measure the effectiveness of the activities that drive the result metrics. For example, measuring the average number of deals closed per salesperson per period would be one measure of the effectiveness of a sales organization (a performance metric) which, in turn, would be a factor in driving revenue (a result metric).

While DevOps literature generally does not provide a lot of detail about metrics, it does provide advice on key result metrics. The primary one is lead time. Lead time is a powerful measurement that originated in Lean manufacturing. It originally dealt with how long it took a company to deliver a product to a customer after receiving an order. In DevOps terms, lead time summarizes the amount of time it takes to deliver one single change or feature from business idea through to running software in Production.

Lead time is calculated by aggregating the work time (referred to as cycle time) on a change plus the time when the change is in progress, but not being worked on (referred to as wait time). The formula that LEAD TIME = CYCLE TIME + WAIT TIME is a powerful tool for understanding the result metric level; however, the challenge in most enterprises is figuring out a workable system of supporting performance metrics.

Value Stream Mapping to Uncover Performance Metrics

You’ll find that the result metrics part of the effort—calculating the lead time for an application change—is relatively straightforward even when corporate structures can obscure exactly when work (cycle time) is happening versus when things are waiting (wait time). The Lean manufacturing world provides techniques for analyzing a flow.

A common technique is called value stream mapping (VSM). VSM provides guidance for breaking down a complex process into identifiable “steps” to provide measurement points throughout the process for cycle time and wait time. The measurement points then provide milestones for tracking the progress of the single change or feature from business idea through to production use.

For example, in an enterprise application development situation, typical application delivery pipelines provide several logical points that can be used as steps for VSM. Using those points, it is simple to measure linear time through the process. The common logical measurement points are:
- Assembly (aka Development): the time required to assemble a configuration package (code, database, infrastructure, and network) that the team declares as an instance of the application including the change
- Time Spent at Each Pipeline Phase: the time spent in various QA environments, such as Integration, Functional, Performance, UAT, etc., and to finally put the configuration package into the Production environment.
- Time Spent on Promotion Decisions: the time spent waiting for a decision to promote a given version of the configuration package to a higher environment or to reject it at the end of that validation phase.
The performance metrics that determine how efficiently cycle time and wait time are utilized, however, are significantly less obvious. Software development is iterative by nature. That means that individual steps in the value stream will be repeated many times and the cycle and wait time metrics ultimately will obscure the quality of what is happening at the measurement points due to natural tendencies to aggregate and average the values.

Performance Metrics for Continuous Delivery

Establishing the performance metrics for a continuous delivery pipeline requires a bit of analysis. The performance metrics must be geared to understanding how to reduce the cycle time per repetition and the overall number of repetitions at each measurement point in the delivery pipeline. Here is a pragmatic, two-part pattern you can follow:

The first part is to break down the iterative pieces of the pipeline into logical ‘mini’ value streams. For example, each QA environment must be provisioned, configured, have changes deployed, and then validation activities occur. Those steps can provide measurement points and, more interestingly, can be used symmetrically in all environments in the pipeline enabling questions such as, “Does one take a disproportionate amount of time relative to the others?”

The second part is to look at the qualitative items that drive either long repetitions or increase the number of repetitions. For example, how many environments does a configuration package go through before rejection? More can actually be more expensive, slower and likely to be indicative of requirements problems, while fewer may indicate code quality problems. Another example might be smoke test failure rate in each environment. Variance in one environment could indicate problems in either the configuration management or deployment automation, but would require repetition of the deployment or manual correction. Finding that problem and fixing it ensures better cycle time at that step and stage, and serves to keep lead time down.

End Game: Demonstrate Business Value

It may be a very long time before the DevOps movement reaches consensus on a system of metrics. The variability in software environments and industry needs means that it is unlikely for one size to fit all. However, with a pragmatic approach and some lessons from the Lean manufacturing world, it is possible to produce a workable and effective system of metrics for continuous delivery pipelines in the enterprise.

Vendors, such as my employer, CA Technologies, are helping by building more integrated systems of pipeline management tools to help shift from merely reporting metrics to applying them with modern analytics-driven techniques. The dividend of these approaches and tool improvements is that it is getting easier to gain a clear understanding of your process and to demonstrate to the business that the DevOps initiative is, in fact, worth the effort and investment.

— Dan Zentgraf
December 22, 2016
A Holiday Tradition: 2017 Continuous Delivery Predictions
It’s that time of year. As the calendar year comes to a close, many of us are following time-honored traditions: making preparations for the holidays, planning some much-deserved time off and enjoying time with friends and family.

In the business world, the year-end also brings its own traditions, and first among those is making predictions for the coming year. I’m not one to forgo traditions, so in this article I’ll share my thoughts on the upcoming year within the context of the continuous delivery movement.

To level set, continuous delivery is the most evolved and modern state of software development and testing—and is core to a successful DevOps strategy. Organizations that are able to achieve continuous delivery can rapidly develop, test and release applications—with higher quality and at lower costs.

Simply put, the ability to more continuously deliver software is one of the biggest advantages to attain in the application economy, where the battleground for consumer loyalty is most often found in the ability to deliver superior applications.

Now that we know what continuous delivery means, let’s get to my predictions for 2017:
1. Continuous Delivery Means Continuous Everything
Continuous delivery is still a relatively new concept, and one that many organizations strive to achieve. As a new concept, it suffers from some of the misconceptions that often plague emerging technologies or trends. Many technology providers latch on to the term and claim to provide “continuous delivery solutions” that in reality only address a small part of the continuous delivery challenge.

Truly delivering software continuously means that all the tasks within the software development life cycle (SDLC) must be optimized to occur in parallel and continuously. This means development must be continuous, testing must be continuous, and likewise for release and operations.

2017 will be the year that industry embraces the importance of an end-to-end continuous delivery value stream. In 2016, many organizations began their continuous delivery journey by addressing certain aspects of the SDLC; in 2017 many organizations will begin to realize a truly open and integrated continuous delivery workflow.
1. Democratization of Continuous Delivery Tools (via the Cloud)
Optimizing all aspects of the SDLC for continuous delivery, as mentioned above, means that related tools need to be easier to use and easier to access. Developers who have access to testing tools (left-shift) can improve the quality of code they produce. Similarly, QA engineers who have access to design requirements sooner can create more accurate test data and scenarios, earlier.

However, for this to occur, the tools have to be both easy to access and simple to use. Developers have avoided complex testing frameworks, but with simple, easy-to-use tools available—often in SaaS forms—developers can certainly incorporate testing into their methodologies.

In 2016, CA acquired BlazeMeter, which pioneered the notion of cloud-based performance testing employing a simple and easy-to-use (yet very powerful) product. We expect to see this trend expand into other tools within the continuous delivery value chain in 2017.
1. The Industry Embraces Open Source (Really)
In the past, we’ve noted that commercially motivated technology providers have tried to keep open-source technology “at arm’s length.” There may have been some lip service paid to openness, but in reality many commercial providers felt threatened by open-source solutions that were seen as competitive to their products.

This perception has already started to change, but I believe 2017 will mark the tipping point where companies will truly embrace open-source solutions as part of their strategy; those companies that continuously resist (pun intended) will be at a significant disadvantage.

Open source is important for many of the same reasons as the cloud: It is broadly adopted because it creates advantage in time to market, quality and cost effectiveness. Embracing open source—and by that I mean both integrating with open-source solutions and using them as part of a product strategy—only makes good business sense. It helps software development teams meet their objectives in delivering quality software faster, and at lower cost.

Another year is rapidly coming to a close and we have a lot to look forward to in 2017.

On the topic of continuous delivery, looking forward means spreading continuous delivery throughout the SDLC, using the cloud more and embracing open source.

All of those things combined will help us advance the continuous delivery movement together as an industry. Here’s to another year of continuous delivery advancements!

Don’t forget, you can also take a closer look at the ongoing evolution of continuous delivery and other DevOps-related trends by picking up a copy of my colleagues’ new book, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory.” If you have some extra time over the holidays, you’ll find it to be an interesting deep-dive.

— Jeff Scheaffer
December 21, 2016
How Continuous Can Integration Be?
My blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps. One of the seven pillars is continuous integration (CI). The blog explained that the pillars are not silos, but rather foundations that need to be kept in balance. A well-balanced CI implementation performs integrations that are fast enough to fit within the time budget for an end-to-end DevOps pipeline.

Compared to older waterfall processes in which large software changes were integrated occasionally, the DevOps CI concept of frequent, small, incremental integrations has many merits. Quick feedback on frequent integration problems enables a release consisting of many individual changes to be built incrementally with confidence. The root cause of integration problems can be isolated much faster when the changes are integrated incrementally. Since faster integrations are better, just how continuous can integration be?

Contrary to the name, integration is never truly continuous. Even if a continuous stream of changes to integrate existed, typical CI process steps (listed below) require a non-zero amount of time. These steps absolutely interrupt the continuous integration cycle to some extent.

• Merge changes in the integration repository
• Check integration repository entry criterion
• Run static analysis scans of the integrated source code
• Orchestrate the build resources
• Create the build
• Save build the artifacts to artifact repository
• Run unit tests
• Save unit test results to artifact repository
• Release the build resources back to the pool
• Orchestrate the functional build test resources
• Run functional tests
• Perform analysis and assessments
• Save functional test results to the artifact repository
• Remediate any problems discovered during the above steps
• Promote the build to the delivery stage
• Release functional build test resources back to the pool.

For CI to perform as continuously as possible, there are three categories of CI best practices:
1. Modularize the product design to support modular CI processing
- Modular code designs, using 12-factor-app principles, allow incremental changes to be integrated.
- Microservice architectures enable each portion of a product to be integrated as available rather than requiring the entire product to be integrated at once.
- Using containers can help to optimize infrastructure orchestration.
- Re-factoring build schedules to remove any unnecessary build dependencies between modules or microservices eliminates time delays.
- All changes are checked into a common trunk branch. This requires the ability to toggle feature changes on and off quickly and easily to enable a release whenever it is needed.
1. Optimize the CI Infrastructure
- Vertical and horizontal scaling of both the CI build resources and test resources creates an infrastructure optimized for each CI stage run.
- Predictive orchestration of CI infrastructures enables CI and test resources and processes to be set up in advance.
1. Accelerate CI processes
- Pretest and pre-check integration deliverables prior to integration to trunk, to minimize costly remediation delays.
- Pipeline CI build and test processes to eliminate setup delays between processes.
- Use Fail fast to prioritize the most important tests as early as possible.
- Use accelerated testing techniques such as risk-based specific test selection to speed up CI testing.
- Use in-process analytics that can detect threshold exceptions prior to the end of the CI build or test process.
- Remediate problems fast using automated rules for roll-backs or targeted problem reporting.
- Establish a policy for deciding when and how to revert changes that break CI processes so that the pipeline doesn’t get stuck when check-in breaks the trunk.
The above CI practices commonly reduce the time for CI from many hours to minutes per build. While minutes is still not truly continuous, for most practical purposes CI processing in minutes is fast enough to suit even the most aggressive end-to-end DevOps delivery pipeline goals.

Summary

What do you think? Do you agree with the above CI best practices? Are there others you recommend?

While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to put in place governance policies that encourage the selection of tool-agnostic IT partners with solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all their IT systems.

— Marc Hornbeek
December 16, 2016