devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

A Six-Step Approach to Enterprise DevOps Transformation

Agility of businesses to transform and adjust to market conditions is perhaps the most important aspect of managing today’s enterprise. With digitization of almost all facets of running an enterprise, it is safe to say that IT agility translates to either the success or failure of such adaptation. Smaller and new-age businesses are better able to adapt, while large, established enterprises struggle or are too slow to adapt. Large enterprises have been executing in an established, traditional way for decades and have solidified their existing processes and decision-making.

New-age businesses don’t have a choice. They have to be agile because of the force to create something new. They either have cloud-native technology support or, even with traditional IT are able to embrace agile, automation and continuous delivery paradigms to stay nimble.

So, what constrains large enterprises? There are three main elements: organization structure, legacy technology stack and culture.

The good news is that there are proven industry approaches to embracing agility in delivering business outcomes. The bad news is that it is quite often a long, arduous journey. This long transformation is often riddled with compromises from “comfort zones,” is potentially career-redefining for executives and practitioners and, of course, requires a fair bit of time and dollar investment.

In my travels and working with many clients across multiple industries, I’ve found that executives do not like terms such as “transformation.” Somehow it is often interpreted as “cost cutting” or “resource realignment” or “outsourcing.” There is some merit in using terms that are appropriate to each enterprise. But, the intent is to transform the way solutions are being delivered today and to do it faster, cheaper and better. The techniques of Agile and DevOps have been successfully implemented in many large and small organizations to enable those outcomes.

To address the three areas of organization, technology and culture, let me present an approach that works quite well for most enterprises. There is always an element of customization of the approach to meet specific needs, but it should provide a basic framework of the activities and potential time frames necessary to implement the transformation program.

The Six-Step Approach

Step One: Initial Planning for Enterprise Readiness

Participants and Inputs, Existing Collateral, Design Thinking, High-Level Outputs

As stated earlier, these steps are customized to each organization, including the participants and inputs, among other factors. For example, the CEO may not be the program sponsor for a given enterprise as it could either come from the CIO or it could be business line-driven. Other enterprises may choose to launch the program at director levels. If possible, this should not be done. The highest chance of success is when the program is championed at the highest levels.

Participants should absolutely include all the towers that make up the solution delivery. Business participation is imperative, along with operations, security and development. I always recommend that the workshops conducted in this step be led by an external experienced consultant or a coach. The key here is to get executive buy-in and create common goals and understanding on what an Agile-DevOps program will look like.

Typically, there are several small DevOps programs already in place in silos that lack maturity to scale to the enterprise level. Design Thinking is a great method to use since it leverages the expertise of all stakeholders, enables them to come to a common understanding, and establishes the needed buy-in. The diagram below illustrates an initial plan for project readiness incorporating the components discussed.

Step Two: Establish a DevOps Center of Excellence

Identify an Executive DevOps Lead with Enterprise Authority

Establishing a Center of Excellence (CoE) is not good enough if it’s not at the right organizational level and enterprise authority. It has to be led by an enterprise leader who has the support and buy-in from all the towers. Active participants of the CoE include representatives from all the delivery towers and also vendor organizations. These participants must be chosen wisely.

I highly recommend that initial phases of CoE be led by an external experienced partner and transitioned over time. The initial phases help cement the vision and strategies of the COE and setup the best practices to support it. Typically, the time to transition from the business partner to internal is 12 to 24 months.

Step Three: Establish Program Governance

Create Communications Plan, Enablement Program, Establish Program KPIs

This is the most important step to make an impact to the culture of the organization. With Agile and DevOps, practitioners’ roles and responsibilities will change. They’ll need awareness, enablement and empowerment to succeed. It is extremely important they understand collaboration between organizations that historically may have had animosity so they can break down these organizational walls. KPIs must shift from individual metrics to holistic customer business outcomes.

Step Four: Establish Project In-take Process

DevOps Subject Matter Experts (SMEs) Conduct Intake Workshops for Scrum Teams

Project intake really sets the tone for how successful each sprint that onboards the program will be. It is not so much about tools and process, but the right sizing of tools and process. There needs to be a fit for purpose in the selection of accelerators, tool chain and development methods. Once established, communication of the intake process needs to occur across the organization. Gather feedback and continually evolve and mature.

Step Five: Identify and Initiate Pilots

Applications Representative of Target Portfolio to Scale

This step has the best chance of success if applied to a specific portfolio of applications or a domain solution. I strongly recommend having some working sessions prior to this workshop to identify an area of development work that represents a portfolio to scale to the enterprise.

The purpose of this step is to conduct a value stream-mapping exercise of a specific application with participants from all towers. This needs to be conducted with the level of detail necessary to identify end to end as-is process, tooling, manual and automated processes, and skills and people involved.

The next part of the project intake is the collaboration of the subject matter experts (SMEs) from the CoE with the project team. The purpose is to advise on “to-be” process with necessary tooling, reusable assets, automation and SMEs needed from operations, security and other applicable areas. These SMEs will comprise the application scrum team. As the application goes through its development/test cycle, identified KPIs for the program are captured. This is absolutely necessary to compare with existing KPIs.

Step Six: Scale Out DevOps Program

Onboard Parallel Release Trains; Apply Intake Process; Support, Monitor and Manage

The final step is to take feedback from metrics of the pilots and scale them by running multiple release trains from different application portfolios. It’s not good enough to just do daily builds and automated deployments. The final piece of the DevOps puzzle is the continuous feedback and optimization.

Summary

The above is an approach that can be implemented in a flavor that best represents each organization’s needs and constraints. Be considerate of large gaps or excessive deviations that may be red flags to be corrected.

Now that you are equipped with the six steps for an enterprise DevOps transformation, you can look at each of them critically, see best fit, and start the journey!

I will be @ Interconnect this year for a session on Environment As A Service. Stop and say hello. Other articles to reference are: “Five things to understand about Enterprise DevOps Solutions,” “DevOps in a Hybrid Model,” and What is platform as a service (PaaS)?”

About The Author/Sunil Joshi

Sunil is an IBM Senior Certified and Open group certified Distinguished Architect. He is currently the Application Innovation Cloud Services Emerging Technology leader. His specialization is in the areas of hybrid cloud solutions, platform as a service and DevOps strategy. Sunil has authored several IBM Redbooks, blogs and also a co-author of the IBM Cloud Computing Reference Architecture (CCRA). Sunil is a regular speaker in the industry on Cloud, DevOps, Microservices, Digital Transformation and related topics. Connect with him on LinkedIn | Twitter

February 3, 2017
Infographic: DevOps Lessons from Lean Auto Manufacturing

Lean principles are as relevant to software delivery today as they were to auto manufacturing in the 20th century. And when you apply lean practices to software delivery, you get the same great results — lower costs, faster cycle times and higher quality.
See the below infographic from Puppet to explore what software can learn from lean auto manufacturing, including the role DevOps practices and continuous delivery play in improving organizational performance, productivity and profitability.

February 2, 2017
Digital Business: Paving the Way for DevOps’ Second Act

DevOps is the buzzword of the moment. It’s at the heart of every strategy—not just CIOs’ IT transformation strategies but also IT vendors’ sales and marketing strategies. The question business unit leaders always ask is, “Is DevOps to improve IT or to boost the business?”

The disconnect is so big between the concerns of today’s DevOps practitioners and business unit expectations on one side and digital competitive challenges on the other that the question is worth asking. Indeed, the proliferation of tech startups and digital services is making competition tougher and forcing business unit leaders to adopt innovation, velocity and timely revenue as their top competitive advantages, helping them to survive their industry disruption and then boost their digital growth.

Let’s say it straight: The many DevOps and even cloud migration projects out there aren’t likely to help business units effectively address the digital economy’s challenges. Automating your application deployment processes with infrastructure as code and continuous delivery infrastructure on their own will never make your company an innovation champion or equip it with the fastest time-to-value in the world. That erroneous belief is nurtured within the IT community; it’s the tangible proof that IT still doesn’t understand the business. Period.

Joe McKendrick, in his fantastic, “The Elusive Mystique of the Digital Enterprise,” and, “Cloud Computing’s Second Act is All Business,” offers insights likely to help business unit leaders remind their CIOs the business reality, “What matters is revenue.” IT innovation for the sake of innovation doesn’t make sense. And Adam Jacob, co-founder and CTO of IT automation company Chef, in a fantastic article, “The Secret of DevOps: It’s Always Been About People, Not Technology,” gives a DevOps vision that’s totally in line with business unit expectations more importantly to more effectively address digital competitive challenges.

Adam Jacob’s System of Thought: The Foundations of DevOps’ Second Act

Adam Jacob defines DevOps as:

Fundamentally being about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.

He adds:

Notice that I don’t mention technology, which may be surprising coming from the CTO of a DevOps-focused company.

He concludes:

Tools matter. But tools exist in service of the prime directive: building highly functioning, highly effective cross-functional teams, that attack your thorniest business problems as a unit, rather than as lone individuals or silos with competing incentives.

This perspective of DevOps unveils an authentic business thinking for IT that I turned into a digital business approach:

It’s represented through the above virtuous circle of principles structured around customer:

Customer is the source of digital wealth: This expresses the proven belief that being customer-focused increases service quality, keeps customers loyal and, in turn, increases his value of the money they spend to buy services. It prevents customer churn caused by changing consumption habits, whereby digital services are increasingly preferred to traditional services.

People make, create and innovate: This principle translates the proven idea that giving staff skills, resources, authority, opportunity, motivation, and holding them responsible and accountable for outcomes of their actions, will contribute to their qualification and satisfaction and ultimately make them committed to the organization’s wealth. It creates work environments and work styles conducive to innovation.

Behaviors and beliefs strengthen involvement and commitment: This principle highlights the demonstrated notion that sharing common beliefs, principles and values creates team spirit, which increases cross-functional collaboration and, in turn, accelerates problem-solving and decision-making. It contributes to the business agility.

Product is the digital wealth driver: It’s the now-acknowledged idea that to succeed in the rising digital economy, businesses must align their application delivery approach to the new product development (NPD) principles. Applications take value to customers. It helps to keep up with the fast-paced digital business environment.

Velocity makes the business responsive to market opportunities: It’s the widely adopted notion that time-to-value is the essential revenue driver that will make businesses digitally wealthy. That principle is enabled by the continuous delivery infrastructure which automates—therefore accelerates—the application delivery processes chain.

This unprecedented vision, dominant on the business side, contrasts with the technocentric approach promoted by the vast majority of IT vendors to increase their sales.

Being honest to customers is telling them this: Implementing continuous delivery infrastructure is not implementing DevOps. It will never, on its own, make the business digitally competitive.

I have no doubt that you’re convinced Adam Jacob, Joe McKendrick and even Ernest Mueller, author of “DevOps: It’s Not Chef and Puppet” are definitely right. The question you might be asking now, which may be provocative is, “Okay, that’s good! How do you implement all that?”

Implementing DevOps’ Second Act Foundations into a Digital Business Capability

The first step toward implementing DevOps is to admit that a new IT paradigm is needed, Adam articulates it that way:

Leaders need to realize that implementing DevOps means changing the technology system as well as the cultural system. They must acknowledge that both are intertwined and, to be successful, both systems must evolve to drive velocity.

It’s not different from the two-dimension IT advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps” and in my online contents, “Become Digitally Savvy in Just Hours. Boost Your Digital Revenue Now“:

DevOps implementation is based on four principles that determines successful business transformation:

Concerns have shifted from technology efficiency to business agility: Forget the outdated idea that IT tools on their own can help your business units succeed. What will make them digitally successful is the combination of technology efficiency and organizational flexibility and agility.

See IT as a two-dimension asset: To win legitimacy among business units, offer a two-dimension vision of IT including the value stream and the continuous delivery infrastructure. Value stream is where value is created and the continuous delivery infrastructure is what enables business agility.

The value stream is where the innovation and agility cultures are built: Transform your business organizational structure into an agile value stream through deploying agile practices and methodologies such as Scrum, Kanban and Exteme programming.

The CD infrastructure is where fast time-to-value is enabled: Automate your applications delivery processes into an accelerated applications delivery chain using automation and continuous delivery tools such as Chef Automation, AWS CodePipeline and Apprenda.

Summing It Up

Experienced DevOps Strategists know that DevOps is the means to an end, and not the end itself. DevOps is an enabler to one or a combination of these business competitive advantages: short time-to-value, market responsiveness, innovation culture and many more.

All the noise surrounding the so-called DevOps tools has to do with technology business—making money through selling IT tools—and absolutely not DevOps.

DevOps isn’t a tool, it’s an IT approach stressing business competitiveness: shorter time-to-value, market responsiveness and innovation.

— Philippe Abdoulaye

January 31, 2017
Culture Comes First in Bringing DevOps to the Mainframe
One of the most difficult challenges in engineering, oddly enough, isn’t technical: the challenge is culture transition management. In my 20-plus years of managing engineering teams worldwide, I’ve led teams through countless organizational adjustments and process improvements toward high-performance and quality, beginning with QA segregation to CMMI to ITIL, AGILE and SAFe.

Today, mainframe organizations have emerged as the focal point for enabling DevOps capabilities and practices. Why the mainframe? Well for starters, business critical applications rely on mainframe data and business components. These applications are mission-essential and that sustained innovation requires solution sets that deliver continuous testing, continuous delivery and continuous feedback on the mainframe platform.

But culture comes first.

Understanding Your Key Players

In conversations with our customers we’ve observed an interesting dynamic emerging within mainframe application development teams. Within these teams are experienced developers who were instrumental in creating the applications that helped make their companies so successful. Over time, many have become set in their ways, adopting a motto of, “If it’s not broken, why fix it?” Such developers are not interested in trying out new things, including programming languages and tools used by the modern-day programmer.

New to the scene are the millennials who have also taken up the mantle of enterprise software engineer. They are a bit more open-minded and bring a different programming language profile, including Java, .NET and C. These developers might be learning how to code APIs with the support of management, and have likely dabbled the basics of how to code iOS apps. Millennial developers are typically much more active online and, as a result, prefer to leverage Twitter and other social channels to stay informed with the development community.

United We Stand

Who, then, should be involved in the journey to realizing DevOps? The answer, of course, is both. Because we’ve heard it reinforced among our users we talk with in the CA Communities every day, at user groups and at prominent mainframe community events such as CA World and SHARE.

You know it, because you probably see it in your organization as well. There are experienced developers: people who have deep knowledge of the applications in place, business intelligence, database tables, cross-application dependencies, batch execution windows and the general experience of how things work on the z/OS platform.

Most importantly, they also know how to avoid breaking what’s working.

And there are the millennial developers: people who are curious to learn about new programming languages, platforms, people who, with the advent of Agile development, and open source have played with things, tested them and are using it to enhance their skill sets.

These people prefer to use modern user interfaces and tools to increase their productivity. Sometimes they might be tentative about making mainframe changes, not willing to risk their careers by breaking poorly documented code.

Culture – Have it Both Ways

While the interests of millennial and experienced developers may at times seem conflicting, both have pivotal roles to play in application development and will benefit greatly from the common sense practices of DevOps and agility that are coming to the mainframe platform. To survive and thrive, teams must unify to facilitate the change process. Most importantly:
- Code must be accessed and modernized at the speed of business. Enterprise developers, testers and architects cannot be afraid to go talk to the “black box” that is the mainframe team.
- Project managers can’t worry that a six-week turnaround for small changes will kill their hopes of meeting their delivery windows.
- The delivery team—QA, release management and operations—can’t afford to sit around waiting for simple deployment steps to happen: when we can automate and integrate to increase deployment frequency.
The promise of DevOps and agility on the mainframe is to fix this, and that’s why our engineering teams are actively building out solution sets that extend DevOps practices to the mainframe, including continuous testing, continuous delivery and continuous feedback.

Curious about what it will take to bring DevOps to the mainframe? Catch some tips and best practices from Forrester Research principal analyst Rob Stroud, or hear from the leaders driving change in their organization in our CA World 2016 Mainframe DevOps panel.

— Aline Gerew
January 31, 2017
Automation Killed QA – It’s Time to Deal With It

Quality assurance (QA) had a good run.

From the time it was considered an afterthought by organizations and software vendors alike to the era of massive outsourcing contracts, followed by significant vendor investments in related tooling, and, finally, its recognition as a critical success factor among high-performing organizations, quality has evolved to become even more important than functionality to end users.

Customer experience, today, is defined by speed and quality above all else. Namely, can I access the information and products that I want in the blink of an eye and get expected feedback based on input? As a result, customer experience has also shifted: It’s all about application experience, not the friendliness of a checkout cashier or sales/service rep.

With this massive shift toward customer experience platforms (think omni-channel) and increasingly lofty expectations, the operative question becomes, How are we enabling velocity in our testing practices to ensure the highest quality while keeping up?

We’ve tried everything from outsourcing to insourcing, investing in tooling, investing in people and even building testing architecture teams to oversee the automation, quality and consistency of testing results. Roughly seven years ago, my top priority for testing teams was to automate 30 percent of our tests. Today, if you are not 100 percent automated, or close to it, you are severely lagging in output.

But what’s next? What if I’ve automated all of my tests and my manual testers have been replaced with automation engineers, but I’m still having quality issues and being perceived as a bottleneck?

The answer is simple. Automate everything.

Makes sense, right? Isn’t everyone telling you that? But what are we defining as “everything” from a testing perspective? Therein lies the problem; we are thinking about testing as its own factory within the larger software development life cycle.

While we believe we are changing this perception by going agile and moving most QA functions into scrum teams, the reality is we still look at testing as a standalone function. Centralized or decentralized, this is the case, and we need to think differently.

Automating for quality begins with defining requirements. How am I ensuring that I’m covering all cases? How do I ensure I’m translating the business requirements properly? These questions, the time it takes to answer them and the risk of human miscalculation all impact quality and velocity.

We must start our automation for quality at the beginning, during establishment of business requirements.

Let me introduce you to next-generation QA. Intelligent “continuous testing” platforms are replacing humans for testing, automating tests, creating data and building test cases. These platforms are able to translate model-based business requirements into complete automation—test cases, test data and test script automation.

Orchestration across your software development life cycle creates your environments, lays down your test data, deploys your software, runs your test scripts and reports results. No more human error, no costly resources and guaranteed test coverage that ensures quality.

Integrating your existing automation around continuous integration, portfolio management reporting, and execution reporting to this framework now gives you the ability to report and automate your ideas all the way through to outcomes.

Early adopters are already doing this. QA as a functional organization is gone. If you aren’t already automating to this end, you are severely behind.

Questions? Comments? Perspective? Have at it in the comments below.

— Ron DeCanio

January 27, 2017
Webinar: How to Build the Right Automation

Many companies are investing heavily in automation. Good high quality automation is key as companies move towards a successful DevOps model. The problem is that automation scripts can be very brittle and tend to not cover or test the entire application. They are also very difficult and time consuming to keep up to date.

This presentation will include a demonstration of how to design, create and update automation scripts as well as their associated test data and end points.

On this webcast learn how to make automated testing a reality.

RECORDING

SLIDES

[slideshare id=71644518&doc=howtobuildtherightautomation24117-170201164235]

— Jules Louis

January 24, 2017
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