devopsy.kinsta.cloud

Author: devopsy.kinsta.cloud

How GitLab CI supported Ticketmaster’s ramp up to weekly mobile releases

It’s always been a goal for the Ticketmaster mobile team to get to weekly releases. In the first half of this year we were able to accomplish it, delivering new versions of both the Android and iOS app on a weekly basis since February. We’ve seen the positive impact on our fans, and it was even easier than we thought – making our entire application development process that much better.

But it didn’t start out this way…

A faster, more consistent release cycle leads to a better fan experience for users of the Ticketmaster Apps.

There comes a time in every engineer’s career when a part of your tech stack no longer passes the “smell test.” Usually, there is some sort of dramatic event where something that was generally accepted as “isn’t the best, but it works” changes to “this is now a problem.” For me and the Ticketmaster mobile team, this event happened with our Jenkins-based CI pipeline in February.

We were about to release the newest version of our Android app, but there was a mistake in the build. We had forgotten to increment the Android versionCode, meaning we would need to update and create a new binary file to upload to the store. It was the end of the day, a sunny afternoon quickly fading to darkness in Hollywood. By now it was 6pm PST, and everyone was eager to leave.

“No problem,” I thought. I can build the release locally in under three minutes, provide the file to the QA team, and we can all get on our way.

“Won’t help us,” responded my high-standard and exceptional QA team.

“All releases need to come from CI for consistency.” They were right. Local builds would not be safe for production. What if something about my machine’s configuration introduced an issue?

“Ok, so how long does it take for the release build to get created through our Jenkins CI pipeline?” I asked, figuring the time couldn’t be worse than 30 minutes.

“It takes two hours,” came the response. Sigh… Going to be a late night.

Our old CI pipeline

GitLab CI to save the day (in a day!)

Two… hours… For a minor change. Now I can’t lay all the blame on Jenkins. Some of this may have been our own fault, generating too many build flavors, forcing clean rebuilds in between steps and running extra tests for deprecated features. But, it was clear we needed to change and get better at CI. Jenkins was always a bit clunky for the last few years. Weighed down by plugins and years of legacy development, it was also difficult for us to update the Jenkins machines with new SDKs, and we had to rely on other teams to assist us. We clearly needed a fresh start.

We had been using GitLab at Ticketmaster for several years for code review and visually browsing our git history, so it made sense that trying to utilize GitLab’s new CI tools would be worth a shot. I started with a helpful Android blog post for setting up GitLab CI from Greyson Parrelli.

But I soon ran into a problem. At Ticketmaster we use Amazon ECR for our Docker container registry rather than GitLab repos, like in the tutorial. With the help of Kraig Amador, Tim Nichols, and others at Ticketmaster, I learned how to push my Docker container image to Amazon ECR and pull it down for each Android build in GitLab CI. The final results were a marked improvement:

Our GitLab CI build and test takes under 8 minutes to build, test, and publish artifacts.

Less than eight minutes total from commit to build, test and generate artifacts. We can use Gradle and the SonarQube plugin to help us calculate code quality with every commit to our codebase, giving us more valuable information in addition to passing failing tests to evaluate all of our merge requests. This gives our team numbers to measure and make goals against.

And we could see everything in one place, in GitLab. The iOS team had a more complicated pipeline, but they quickly followed with their own, running their tests on local runners. Since February we have had weekly releases of our mobile apps, and GitLab CI has been a huge part of our success over the past few releases.

From GitLab artifact to weekly releases

GitLab CI has helped us get to weekly releases with more consistent adoption of new releases.

With the benefit of faster cycle time, and faster releases, we have seen other benefits. Since each release has a smaller change set, our crash-free rates and store ratings have improved. We have less time waiting for build and spend more time improving the quality of our products. Our fans are getting features into their hands more quickly and benefit from a higher-quality and a consistently improving product. The CI analytics available on GitLab are an additional scoreboard for our team to optimize and improve into the future.

Now, whenever we integrate new SDKs into our mobile apps, we are helping other teams get their SDK’s set up in GitLab CI to push integrated builds to our suite of integration and functional tests as a part of our process. We are getting to innovation faster.

Things were looking pretty scrappy for our CI pipeline only a few months ago. Now it is a whole different ballgame. If your team is looking for a way to breathe fresh life into a legacy CI pipeline, I suggest taking a look at GitLab CI. It has been a real game changer for our mobile team at Ticketmaster.

About the Author

Jeff Kelsey is the Lead Engineer for Ticketmaster’s Android development team. Find him on twitter @jeffkelsey.

August 15, 2020
Increasing deployments to 10 times a day

BI WORLDWIDE (BIW) inspires people and delivers measurable business results. Inspired employees solve problems and create value. Inspired salespeople take risks and seize opportunity. And inspired channel partners and customers choose your brand every time. We work with great companies around the globe who know that extraordinary results can only be achieved when their business is energized by the people who make it happen.

the challenge

Updating legacy systems and moving to multi-tenant configuration

The BIW Corporate Product Development Team (CPD) was dealing with a large legacy codebase that was created years ago. They were looking to eliminate (or at least significantly reduce) manual testing and manual deployments to their on-premise infrastructure. They had maintenance backlogs, inefficiencies, and cross-organization visibility issues. The goal was to achieve operational efficiency by removing toolchain complexity.

The company was also trying to update the previous architecture of a single-tenant code-change-driven solution and upgrade to a multi-tenant configuration-driven solution. The legacy application installation pattern was to install from a fork that could (and would) be tweaked to a customer’s needs before deploying to the VMs. This pattern provided flexibility for customers but was inefficient and was time-consuming to maintain and upgrade.

“It was entirely time-consuming to apply all of those code changes,” said Adam Dehnel, product architect, BI WORLDWIDE. “As a result, we didn’t release as frequently because the application of a new release to those disparate installations was quite a process. That would cause us to try to get ‘all the features’ into each release which would then slow the process down more.”

the solution

Increasing development speed

The Corporate Product Development Team considered Git source code management while using CVS in 2014. At that time they achieved 9-month release cycles with another few months for the code to be distributed to the customer installations for the upgrade. This tempo impacted their pace of delivering to market and ability to respond to customer requests.

To help combat this pattern, the product architecture team was given the directive to rethink processes – essentially update and modernize everything. They had practices and tools in place at the time but were spending time on items that weren’t business differentiating features. They faced classic issues surrounding a lack of cross-team communication including inefficient mechanisms for intra-organization workflows and individualized toolsets.

One of the early moves to help solve these challenges was to migrate from CVS to Git for source control management. They experienced a self-described “painful transition to Git” because of the modernization efforts this move required. Once the initial move to GitHub was complete BIW began looking to automate the build, test and deployment process. As the first implementation of this, the team built a chain of tools with GitHub talking to Jenkins and then Checkmarx + WebInspect plus JIRA and Confluence for the setup to manage the full lifecycle microservices. While these tools were heading in the right direction, the organization was still facing challenges with toolchain complexity and experienced lost bug reports, constant context shifting and tool differences throughout the organization.

the results

Improving efficiency by moving to a single tool

The CPD team evaluated GitLab’s capabilities against their current toolset and against the competition and selected GitLab to help them achieve their next iteration. The group started looking at what tools they could remove to simplify their toolchain. The migration from their previous Git tools to GitLab was painless and they saw an immediate improvement of collaboration and release pace as a result of their move to GitLab.

The development, QA, UX and DevOps teams within CPD at BIW have been using GitLab since 2017. In June 2018, additional development groups started to move over to be able to easily track all features, stories, requirements and use cases in GitLab Issues. The next goal is to include ongoing bug tracking and expand GitLab to several new internal teams that will use it as a collaboration hub for future feature development requests and discussions.

“GitLab is currently running on a Rancher cluster and we’re using AWS Aurora Postgres + Elasticsearch to run it. And then we just recently migrated from a (different) Rancher cluster for our microservices to Amazon EKS and are also pushing our web applications to CloudFront,” Dehnel explains. “All of this deployment is running from GL pipelines. We are solidly in a good CI workflow with some applications in Continuous Delivery. Heading into 2020 we’re starting to push towards Continuous Deployment for all microservices and microexperiences. We hope to leverage some of the GitLab Kubernetes integrations and enhancements to make this transition less work and more consistent.”

The company recently started using GitLab Pipelines to scan (SAST + Dependency initially, but they plan on using DAST capabilities soon) and deploy legacy monolith installations for anyone that is running their install in AWS. Between this setup and the microservices running in GitLab pipelines the first four days of SAST/Dependency scanning the team performed over 300 scans. This scanning helped the team identify previously unidentified vulnerabilities and allowed them to rectify the situation going forward. GitLab’s pipelines allow everyone to use the same tooling for application scanning and deployment regardless of whether it is legacy or modernized.

While Dehnel admits that they are still using some classic methods, they now have teams that experience releases almost daily– down from the original pre-Git pace of a release every 9-12 months. BIW is using GitLab pipelines to deploy the legacy monolith to AWS. Within those pipelines, they are performing automated infrastructure provisioning, infrastructure as code, automated security tests, and application deployments.

The ultimate win for the company is that the corporate product development team is all working in the same place. The operations infrastructure team is now working from the same platform and using the same product for their software development lifecycle. The team is pushing all of their automation tools to the same place instead of working around a daisy chain of tools anymore.

“One tool for SCM+CI/CD was a big initial win. Now wrapping security scans into that tool as well has already increased our visibility into security vulnerabilities. The integrated Docker registry has also been very helpful for us. Issue/Product management features let everyone operate in the same space regardless of role.”

Adam Dehnel

product architect, BI WORLDWIDE

All information and persons involved in case study are accurate at the time of publication.

August 15, 2020
5 Principles for Securing DevOps

DevOps, a new model for software development, is transforming the way the world creates software. And despite its substantial organizational, cultural and technological requirements, this new way of organizing development and IT operations work is spreading rapidly.

To read more about DevOps and how to secure it, download the PDF here:

[su_button url=”https://devops.wpengine.com/wp-content/uploads/2020/08/Veracode_5-Principles-Securing-DevOps.pdf” target=”blank” background=”#ef2d3f”]Download Now[/su_button]

August 15, 2020
How-To Stop Copying and Pasting Flaws Using Open Source Code

In this video, learn how to prevent critical flaws in your copying and pasting methods using open source code through this video presentation from Brittany O’Shea, Senior Product Marketing Manager at Veracode.

To watch the full video, download it here:

[su_button url=”https://devops.wpengine.com/wp-content/uploads/2020/08/Veracode_How-To-Video_Open-Source-Code.mp4″ target=”blank” background=”#ef2d3f”]Download Now[/su_button]

August 15, 2020
State of Software Security – Open Source Edition

For our State of Software Security: Open Source Edition report, we analyzed the security of the open source libraries found in 85,000 applications. Below are highlights of that analysis.

To see these highlights, download the infographic below:

[su_button url=”https://devops.wpengine.com/wp-content/uploads/2020/08/Veracode_State-of-Software-Security_Open-Source-Infographic.pdf” target=”blank” background=”#ef2d3f”]Download Now[/su_button]

August 15, 2020
Understanding Modern Software Development: What Security Professionals Need to Know

There has been a noticeable shift from a monolithic architecture to services- or microservices-oriented architecture. Microservices architecture entails breaking applications into smaller, interconnected services instead of one large, monolithic application. The reason for the shift is likely due to the fact that microservices architecture is faster to develop and easier to maintain. Unlike monolithic applications that are hard to make changes to, microservice applications can be adjusted on the fly.

Organizations are also moving away from manual processes in favor of automation – this includes both automated deployment and application security (AppSec) tests. Automation has enabled organizations to move from quarterly software releases to weekly or monthly releases.

To learn more, download the Infosheet here:

[su_button url=”https://devops.wpengine.com/wp-content/uploads/2020/08/Veracode-AWS_Modern-Software-Development.pdf” target=”blank” background=”#ef2d3f”]Download Now[/su_button]

August 15, 2020
Axway realizes a 26x faster release cycle by switching from Subversion to GitLab

Inventors of the world’s first business rules engine, Règle du Jeu (RDJ), Axway has been helping businesses unlock the value of their data for nearly two decades. Their cloud-enabled data integration and engagement platform, Axway AMPLIFY, orchestrates cohesive customer experience networks, enabling organizations to generate the speed, power, and agility required to meet skyrocketing customer expectations.

As change agents for data integration, keeping pace and adapting quickly to today’s fast and fluid digital customer is mission critical for Axway’s research and development (R&D) engineering services teams.

the challenge

Legacy source code management and toolchain complexity limits worldwide collaboration

Serving over 11,000 companies spanning 100 countries, Axway’s R&D engineering services teams are spread across continents and time zones. With the teams working from nine different sites and using Subversion (SVN) on local servers for source control management (SCM), collaboration between the globally distributed teams was suffering, preventing them from implementing DevOps.

“Our legacy toolchain was complex, disconnected, and difficult to manage and maintain,” said Eric Labourdette, Head of Global R&D Engineering Services and responsible for worldwide R&D operations including DevOps. “SVN was difficult to administer and didn’t scale, causing extra administrative overhead. It became unmanageable for our team size.”

As the organization looked to move to a microservices architecture and implement DevOps, they needed a solution for SCM that could foster collaboration across locations and projects, and support DevOps practices like continuous integration and automated deploys.

the solution

GitLab for SCM enables DevOps

A modern solution that can be hosted on-premise, GitLab provided a single instance of source code for the entire company. Leveraging a Git-based workflow, Axway’s worldwide R&D teams can now easily share and collaborate on code with nearly zero downtime and minimal administrative overhead. Leveraging the most robust Lightweight Directory Access Protocol (LDAP) support of any SCM provider, with GitLab, Axway is able to manage access and permissions for 600 enterprise developers securely and consistently.

“GitLab offered the most advanced feature set on the market.”

Eric Labourdette

Head of Global R&D Engineering Services

“GitLab met our requirements and gave us the best value for the price,” said Labourdette. “The feature set with GitLab on-premise was more advanced than GitHub and we saw the pace and development [of GitLab] moving faster with a community that was active in delivering and contributing.”

Collaboration between development and operations teams improved, too. Using GitLab’s Jenkins integration, developers can trigger their own builds and see the output of the pipeline status in the same view as their code within GitLab.

“All of the development we have done starts with central source code management in GitLab. This is followed with ephemeral Jenkins through GitLab CI to “eat our own dog food” in creating pipelines that build and deploy images then QA them and execute a security scan. Immutable infrastructure and common continuous deployment using Artifactory and Bintray repositories allows us to deploy Docker container images into AWS. Our new development is based on microservices, Docker on Kubernetes with GitLab being the source of our DevOps pipelines,” Labourdette explains.

the results

Faster release cycles and soaring adoption

Now, with developers empowered to self-serve with minimal guidelines, the DevOps teams at Axway have improved their release cycle time from annual releases down to two weeks for some products.

In using a bottom-up approach to choose their SCM solution, adoption of GitLab was unsurprisingly fast and natural. In just one year, 630 users were onboarded and 3,000 projects were migrated. “Everyone was asking for it,” said Labourdette. “Now, every single developer is running on GitLab without enforcement.”

All information and persons involved in case study are accurate at the time of publication.

August 15, 2020
How Financial Services Companies Compete Better with DevOps
What will it take for financial services companies to compete (and win) in today’s software-driven marketplace? There’s no question the sector is hyper competitive – and getting tougher all the time. Tightening regulations, roller-coaster markets, competition from innovators and disruptors and consumer demands are keeping every player on its toes.

On the product development front, many financial services companies are challenged to keep up. Tool sprawl, legacy systems, calcified processes and the lack of automation can slow innovation and hobble efforts to meet compliance and governance mandates that get stricter every year.

Market leaders know that it’s no longer enough to be a great bank. The best ones are transforming to become digital disruptors and using DevOps principles to propel growth with innovation, out-compete rivals and deliver value to customers faster.

I recently hosted a webinar featuring executives from U.S. Bank, Broadridge and Forrester to find out where the financial services industry is headed and the ways digital transformation is turning great banks into technology-driven powerhouses.

These experts agree on the big picture: There’s a historic transition underway from brick and mortar banking to a new digital-centric world characterized by banking everywhere, anywhere and anytime.

This new reality is putting pressure on banks to fundamentally rethink how they deliver and govern new digital systems and redefine customer value.

A better way to innovate

To be competitive in the sector today, experts told us, innovation is paramount – even more so than speed. “While it helps to be fast, the focus should be on leveraging speed as a buffer that affords you the time to innovate and discover new routes to value,” says Charlie Betz, a principal analyst at market researcher Forrester.

Innovation will require experimentation, Betz says, and also a new form of decision-making. It’s an approach that is akin to going through a revolving door: It’s easily reversible. Of course, that way of thinking is what DevOps is all about: Continuous integration, automated delivery and a reliance on fast feedback so you can make fixes and changes earlier rather than later.

Think of it this way: By the time you pack that parachute and walk through that revolving door, the competition has been around that door half a dozen times and figured out a better way to deliver value to customers and has taken some of those customers from its competition. It’s no surprise, then, that when it comes to DevOps priorities, the leaders we talked with are focused on “shifting left” — that is, moving software testing and feedback closer to the early stages of development, allowing for faster fixes and more efficient experimentation.

Driving developer efficiency

At many financial services companies, a crucial objective for IT is to boost developer productivity, which in turn can help increase software velocity and quality. Measuring efficiency can be a bit elusive, though, but Steven Weinstein, senior vice president of technology service and solutions at Broadridge Financial settled on a good proxy: the number of Jenkins jobs they run per month. (They are currently up to 30,000 per month and increasing that total by 2,000 new jobs per month.)

Steven Weinstein, senior vice president of technology service and solutions, Broadridge
“By using CloudBees, we estimate we can save 15 to 25 minutes per run, freeing up developers to focus on product enhancements, eliminating software vulnerabilities and accelerating time to market,” Weinstein says.

Leaders also stress the importance of driving consistency and knowledge sharing across teams, and many are moving to a common software deployment platform powered by a single, integrated portfolio of tools. Breaking down silos and fostering cross-functional enterprise teams are important priorities for many of these organizations.

Others are ensuring a common experience by moving development to the cloud and mandating the use of a shared set of automation processes and tools prior to moving there. They are also sponsoring DevOps “communities of practice,” centers of excellence and self-service portals to help developers thrive in the new environment.

New governance models

Governance and regulations loom large in the financial services world and the leaders we talked to felt that the process of governance will change significantly in the digital era. Although the process would be slow, ultimately the new governance model must become more focused on principles versus processes. “It will be more about ‘what,’ not ‘how,” Forrester analyst Betz told us.

Specifically, a new governance model will need to accommodate increasing levels of technological dynamism, such as microservice-based architectures and continuous delivery, which is swiftly replacing what used to be a fairly predictable transactional architecture.

Experts foresee the end of “stage-gated governance” – a model better suited to the old world of “waterfall” software development. That’s when you paused after every “batch” so experts could come in to check over the code. “It’s like when guards in medieval times checked your cart before you could enter the city gates,” Betz says. “The industry will need to replace that model with new governance models based on the continuous software flows that now predominate in DevOps-powered organizations.”

Getting started

How do financial services firms get started on their journey to a DevOps transformation? Leaders say that it’s smart to start small with a project that you can be reasonably sure will generate business value. Getting early wins will inspire confidence among developers and business colleagues.

Swati Shah, senior vice president of emerging technology, U.S. Bank

What’s more, don’t take on too much risk by experimenting with a project that could put the business in jeopardy. And for the same reason, don’t try to tackle too much at the same time. “Don’t try to bottle the ocean,” says Swati Shah, senior vice president of emerging technology at U.S. Bank. “Start small then gradually go faster.” It’s also safer to target components that are architecturally modernized, such as APIs and microservices, which allow for faster experimentation. Finally, Shah recommends choosing a team of people who are genuinely excited about DevOps and passionate about learning new things. “This will help ensure success,” she says.

It’s about outcomes!

At the end of the day, financial services leaders say that the goal of DevOps shouldn’t be about DevOps itself but about business outcomes. DevOps is not an end in itself. It’s about striving for particular outcomes, making things better for our employees and more importantly, our customers.

Learn more about how DevOps can help financial services organizations compete better by clicking here .
August 3, 2020
Overheard at CloudBees Connect: The Reality of Delivering Modern Software
What’s it like delivering modern software today? We posed that question to eight DevOps leaders from a diverse range of industries and development organizations. They were all participants in panel discussions I moderated at CloudBees Connect – held virtually this year. Needless to say, there were no short answers to our questions, but here’s a sampling of some key issues they’re focused on.
- Balancing speed with security, compliance and quality. DevOps leaders say they constantly wrestle with getting the best of both worlds. Many err on the side of caution, but also take advantage of automation to embed security safeguards throughout the lifecycle without diminishing speed. “We want to empower our customers and our engineers, but we need to delight our auditors,” says Jennifer Hansen, director of product management and delivery experience at Capital One.
- Standardization versus empowerment. You need both to thrive in today’s environment, panelists say. “The key is to find that sweet spot between maintaining a structure that your organization needs and giving developers the freedom to drive innovation,” says Daniel Ritchie, distinguished engineer at Broadridge Financial Solutions. Some standardization is helpful, and many programs have adopted common patterns and core toolsets to boost efficiency, but not at the expense of best in class tools that the developers want to use most.
Sanmat Jhanjhari, lead DevOps engineer, Nationwide Building Society agrees. “Nationwide believes in empowering people and creating an environment that you have [what we call] accountable freedom…that’s one of the key pillars of [our] leadership framework.”

“We really want them to be involved in the pipeline construction and to tell us what they need rather than for us to describe or define what they should be doing,” says Bob Kelley, director of delivery engineering, IHG.
- Culture not tools. People and culture – more so than tools – are the key to building great software for customers. That’s why continued learning and skills development is a prime focus of Capital One’s Hansen. “We’re trying to create a shared experience and responsibility across everybody on our team.”
- Scaling up. Organizations large and small need headroom to grow. Even smaller companies are preparing for the day they’ll need broad-reaching capabilities. Says Adam Robertson, head of DevOps at Pinger: “We’re building the foundational elements so we’re ready when we reach enterprise scale.”
- Embracing the future. Leaders say they are enthusiastically embracing the latest development approaches and technologies, including microservices architectures and containerization in the cloud.
- Winning over management. Convincing C-suite execs that DevOps is worth the investment can be tough. Jimmy McNamara, software engineering product manager at Fidelity Investments, says the best way to overcome resistance is to “use data to show real outcomes. It’s about articulating a vision of value and demonstrating that in a very tangible way.”
- Driving collaboration. Leaders have adopted different techniques for promoting collaboration among developers. Some have created open source communities within the company, complete with templates and global libraries, to help developers contribute code and allow other teams to benefit from the contributions.
- Move slow so you can move fast. Leaders say the best way to build momentum across teams is to first establish a consensus, so everyone has shared ownership and feels empowered at the same time. That may take time, they say, but if you invest upfront, you’re going to reap returns faster, longer and better later. “Instead of dictating to teams, we need to create consensus up front,” says Aoife Fitzmaurice, architect for enterprise cloud computing at Fidelity Investments. “If a certain choice wasn’t correct, let’s work together to make the right choice.”
- Harvesting best practices. The diversity of practices across engineering teams can be a strength to development organizations, Fidelity’s McNamara says. DevOps can serve as a “central consultancy” that can “harvest their best practices” to empower the whole organization.
What else is on the minds of DevOps leaders today? Listen to both panel discussions – captured in the award-winning CloudBees podcast, DevOps Radio, to dig deeper into the reality of delivering modern software today:
- Episode 73: Live from CloudBees Connect – The Reality of Delivering Modern Software: Part 1 Listen Now
- Episode 74: Live from CloudBees Connect- The Reality of Delivering Modern Software: Part 2 Listen Now
August 3, 2020
The 2020 State of Software Delivery Management Report

To read the latest software industry research from Accelerate Strategies Group, download the report. To hear ASG discuss the results, listen to episode 77 of DevOps Radio here.

Despite years of embracing DevOps, organizations are nowhere near extracting maximum value and efficiency from their software delivery pipelines. That’s one of the key takeaways from a just-released survey of software organizations by Accelerated Strategies Group, an analyst company whose mission is to democratize access to industry expert knowledge.

The survey’s author, Principal Analyst Sanjeev Sharma from Accelerated Strategies, and Mitch Ashley, the company’s CEO, shared this frank assessment during a wide-ranging discussion with DevOps Radio about the current state of software delivery management in the enterprise. “Organizations are still working in silos 10 years after the DevOps movement started,” Sharma says. “And they’re still struggling with breaking down those silos.”

The fragmented development environment hurts productivity by blocking the flow of information from the people who have it to the people who need it. “Cross-silo information flow is still really bad,” Sharma says. “You have to jump through hoops to get the information you need to do your next task.”

CEO Ashley agrees. “Our mantra is ‘knowledge wants to be free,’” he says. By identifying and clearing bottlenecks in the flow of information across function, companies can better understand the business value of their software and deliver the “right software at the right time at the right place.”

Sharma says the point of effective software delivery management isn’t about deploying software faster or more frequently, but producing successful business outcomes – and that requires connecting the software development process with meaningful business value. “It’s totally irrelevant how fast you’re going if you’re going in the wrong direction,” he says. “That just results in software nobody uses, and it’ll cost you more to get back on track.”

Ashely and Sharma say companies will need to improve software delivery management to deal with the profound transformations happening in today’s economy, from the shift to remote working and commerce, to increasing cloud adoption, to the impact of emerging technologies like AI and machine learning. “When you’re talking about how you’re going to engage a customer and how you’re going to change your business model, those experiments, if not done properly, can result in investing a lot of money down the wrong path,” says Sharma.

In the recent survey, Accelerate Strategies segmented front-line “practitioners” from management-level “non practitioners” and found that most developers didn’t have as much visibility into the data as top managers. Too many managers believe that the data is for their eyes only and often try to control and sanitize the data before reporting it “upstream” to executives.

The result is that “practitioners feel cut off, they feel lost,” Sharma says. “It’s these cultural attitudes, these us-versus-them mindsets, that are contributing to the problem.”

The split can potentially sap the organization’s effectiveness, the survey suggests, often giving leaders a rosier view of what’s really happening on the ground and preventing development teams from making the fast course corrections needed to navigate a volatile market landscape. “If you believe you need to be able to fail fast, you have to be able to fail,” says Ashley. “You just have to do it on smaller scales, much quickly, and learn from it very quickly.”

The best strategy, Ashley and Sharma say, is to make data freely available to anybody who needs it through the right kind of dashboards, with appropriate security safeguards. “The mentality of joint ownership is what really creates the right environment for end-to-end software delivery management, where everybody has a part in the process,” Sharma says.

Tune in to Episode 77 of DevOps Radio to hear more from Sharma and Ashley about the state of software delivery management and their personal experiences navigating the world of DevOps.

August 3, 2020