Key Takeaways from Continuous Discussions (#c9d9) Episode 80 – CloudBees Customers Speaking at DOES17

Written by: Electric Bee
1 min read
Stay connected

We recently hosted a special episode of Continuous Discussions (#c9d9) , featuring some of our customers and partners presenting at DevOps Enterprise Summit San Francisco (DOES17) .  During the discussion, they shared some of their recent DevOps transformation stories and a bit about what to expect during their talks at the conference. The panel included: John Esser, senior director of IT and data center operations at AdvancedMD; Gary McKay , scrum master at Somos; Aloisio Rocha , agile product owner at NetEnt; Manish Aggarwal , software engineering manager at Intel; Marc Priolo , global software configuration manager at Urban Science; J. Paul Reed , managing partner at Release Engineering Approaches; Marc Hornbeek , principal consultant – DevOps at Trace3; Gary Gruver , founder and CEO of Gary Gruver Consulting; and, our very own Sam Fell and Anders Wallgren . As we inch closer to DOES17 Sun Francisco, here are some of the key takeaways from the recent #c9d9 discussion.

Every company is different, so approaching a DevOps transformation will vary based on the organization, explains Esser : “Every company has a different set of constraints, a different culture, different things they value. So you can't just say, ‘Oh, I've got this DevOps hammer, and I'm going to start pounding away.’ We understand the principles, but how to apply those and how to execute those principles are quite different.”

McKay on the success of moving from mainframe to microservices with his ‘Team Dragon’ concept: “Team Dragon was formulated to make sure that our CI/CD process, as well as our deployment and release processes were consistent. Coming from a mainframe environment to, say, a distributed microservices environment, there are differences not only in culture, but processes and technology. We wanted to make sure all that was managed efficiently and effectively, so that we could do deployments when we needed to do deployments.”

Rocha on the NetEnt DevOps journey and what inspired the transformation: “We’ve gone from a place where the business was expanding, but deployments and deliveries were not scaling with the business to working on how to tackle it with automation, working with the deployments and making the deployments visible to everyone.”

Aggarwal will be talking about the DevOps journey at Intel at DOES17: “I will be covering as to how a lot of organizations, including Intel, are trying to board the journey of DevOps. They are successful to an extent, but how to make sure that the quality, which is the sole purpose of this journey, does not get left behind.”

 

Priolo on his pipeline-as-a-service strategy: “We have a pipeline-as-a-service strategy. That's where we want to make sure that our developers can concentrate on developing instead of trying to figure out how their code is getting into our production environment.”

 

Gruver ’s simple advice on starting your DevOps transformation: “In the beginning, you need to create some positive momentum. You need to find the things that are the most broken in the development and deployment operations. You need to highlight them. You need to get them fixed. Then you need to market those changes, so that you get some positive momentum for the transformation.”

Don’t forget about the human factor of release engineering, says Reed : “At DOES17 we’re going to be going through a little bit of the human factors that are related to release engineering. There's a couple of facets of that. It's sort of, ‘How do you go about doing the work,’ and then also a bit about how we treat others, the net system.”

 

It’s important to include all teams on your transformation journey, per McKay : “The secret is inclusiveness. Making sure that the mainframe team is part of the microservices process and making sure that we, in our haste to get things done very quickly and very effectively, make sure that we bring them in. We make sure that their roles are purposeful and that they're part of the process and not just, ‘Oh, you're just some mainframe guys. We're just going to ignore you.’”

Esser on the core values of DevOps: “DevOps as a whole is not limited just to an architecture. DevOps, at its core, is about working better together and increasing the flow of value across the whole value pipeline.”

 

It’s important to find the right balance between allowing your developers to be unique, but also adhering to the rules, says Priolo : “The real challenge is trying to find a way to allow developers to still have their snowflake ability, while still complying with the standards of the company. It's not to make everything stringent and follow the same exact path. It's to create a pipeline that gives them the flexibility, but still gives us the ability to do auditing, to make sure that the code is being checked at its proper place.”

Sometimes it takes a big mistake or bug to make you realize you need DevOps, explains Rocha : “Our process was intense before, to say the least, especially when some scary bug came or a heavy compliance requirement came in that we had to fulfill in a short amount of time. That made us realize we have to fix this.”

Wow - Aggarwal ’s team at Intel went from almost complete manual testing to 100 automation: “When we started about seven years ago, 99 of our testing was manual, and everything was repetitive. The work was getting more challenging, and the sheer amount of it was growing with every release. So it was very important to bring that under control. The only way of doing that was end-to-end automation. When I say, ‘end-to-end,’ it's not 99. It's 100 totally touch-less automation.”

Reed on the human factor of versioning: “Versioning really is about humans communicating with each other. They're trying to encode information into that version number, which is, I think, one of the reasons you see people bikeshedding that a lot.”

DevOps can expose your long-standing problems, says Gruver : “When you start trying to increase the frequency of build/test cycles or deploy cycles, you see inefficiencies repeating. You see the trends. There's a bunch of tools in the DevOps toolbox that enable you to go after that.”

Moving from monolith to microservices is not an overnight transition, explains Wallgren : “Time and time again we hear the difficulties that everybody has with legacy applications or monolithic applications. The transition away from mainframes is not an overnight kind of thing. They're not going anywhere, anytime soon.”

There’s still value in mainframes, and getting that to customers is key, explains Fell : “There's a ton of value locked up in mainframes and being able to get that out to other people in a service-oriented sort of way. It's a hard migration to do, but that cultural aspect of making teams feel like they're comfortable working with one another is critical to getting through that part of the process.”

Watch the full episode:

Here from these DevOps experts and MANY others!

DOES is selling out - register today! Register for the conference  

Want more Continuous Discussions (#c9d9)?

We hold our #c9d9 podcast every other Tuesday at 10 a.m. PT. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.

This post originally appeared on DevOps.com

All Blog Articles

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.

Related Content

YAML Declarative DSL Preview for CD/RO

Blog
6 min read

What Is Continuous Deployment? A Complete Explanation

Blog
6 min read

YAML Tutorial: Everything You Need to Get Started in Minutes

Blog
8 min read

Let's Get Back to Coding! 5 Approaches to Solving Pipeline Bottlenecks

Blog
12 min read

Integrating DevOps value into business goals

Blog
3 min read

Why Current Approaches to "Shift-Left" are a DevOps Antipattern

Blog
7 min read
Capabilities
Resources
Why CloudBees
© 2023 CloudBees, Inc., CloudBees® and the Infinity logo® are registered trademarks of CloudBees, Inc. in the United States and may be registered in other countries. Other products or brand names may be trademarks or registered trademarks of CloudBees, Inc. or their respective holders.
Privacy PolicyTerms of ServiceCloudBees Vulnerability Reporting