Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

To Be Continuous: DevOps [Podcast]

DZone's Guide to

To Be Continuous: DevOps [Podcast]

Sam Guckenheimer of Visual Studio Team Services talks about how CI/CD has shaped DevOps and will continue to do so in the future.

· DevOps Zone ·
Free Resource

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

In episode 45 of To Be Continuous, Paul and Edith meet with Sam Guckenheimer, Product Owner for Microsoft’s Visual Studio Team Services. They talk about how CI/CD has shaped the way teams approach DevOps today and how things might look in the not-so-distant future.

This episode of To Be Continuous is brought to you by Heavybit. To learn more about Heavybit, visit heavybit.com. While you’re there, check out their library, home to great educational talks from other developer company founders and industry leaders.


About the Guests

Sam Guckenheimer is Product Owner for Microsoft’s Visual Studio Team Services (VSTS) where he supports and promotes agile software development and continuous delivery with the One Engineering System.

Transcript

Edith: Now would be a good time for you to introduce yourself.

Paul: Right, all their ways you can write code.

One of the things I try to do is to share as much as I can about our own experience.

So I curate a website DevOps at Microsoft, AKA, .MS WAC DevOps, and share things like how we use Git and how we change our test portfolio.

An example is that in my talk yesterday at Index I was showing how we use our pull request policies to run 70,000 tests in about six minutes. And that's on every pull request uniquely. If any of them fail, we fail the pull request. And if the co-review doesn't happen within 12 hours, we fail the pull request.

Paul: One thing I find very interesting about this is that the way you're describing, it's a very integrated system. In my past life when I was at CircleCI we dealt with the GitHub ecosystem, lots of tools, very sharp tools that did one thing well. In my new startup, I'm very much more in the, "Let us make one tool that does everything and is awesome."

What's that experience like for your customers, for the people who are working on the system where you have that one holistic system? What can you do that you can't do the other way?

Paul: I've heard of them.

Edith: Thanks for wearing the shirt.

Edith: This is definitely a shift from the Microsoft of the past.

Sam: Oh yeah. If you mean the Microsoft five years ago, it definitely is. I mean, one of the things I talked about yesterday at Index was our open source contributions. If you look at last year, 2017, the company with the highest number of contributors to open source on GitHub was Microsoft. And Google was a little bit behind, and then everyone else was way behind if you look at that. If we're not the top, we're one of the top two contributors to Git, top three to Kubernetes and so forth.

Sam: Yeah. I had a few VPs on this panel with me. One of them is Gabe Aul from Windows & Devices. He made a very clear point that the most important metric for them is engineering satisfaction with the engineering system. So in other words, how happy are you with the tools and process? And how much does it improve your work and is it better than three months ago? And so on. He pointed out, that's what we're optimizing for. We're optimizing for that next generation.

Edith: So your 75,000 developers, it just keeps coming back to us, that's a great quote, a great number. How do you then relate that? What works at Microsoft scale might not work for somebody smaller, or vice versa. Or I guess the bigger question is what do you see in amongst the base of how are people adopting continuous delivery in al these trends. In other words, we try things on ourselves and make them work as part of our One Engineering System, and then take them to market through things like VSTS.

Sam: Right, or 400. Absolutely true. But the case I always make is, look, we didn't start cloud-native. We have these long code lines. Including in my group, we started with an on-premise team foundation server, which was frankly written as a monolith. And we have been over years refactoring that into microservices.

The beauty of that is that I can say, look, our baby is ugly, too. If you say your baby's ugly, you get the people to say, "Well, not really," right?

And you get to talk about your problems and you get to say, look, these things, here are some things that took years.

Sam: Well, let's go to the Hello World part of the question first, okay? So today, I can't demo this on a podcast, but you can literally start at the Azure portal, click the plus sign for "create a new resource," click DevOps Project, and you then choose what technology do you want to work with, Java, Node, .NET, Python, etc.

Based on that, then what framework do you want, if it's Java you got to pick Spring or something else. If it's Node you get to pick Express or something else, or whatever. And then do you want this on, do you want this containerized on Linux, do you want this on straight Windows VM? And then you identify which account, and you click Start, and in four minutes you have a Hello World site that is deployed in the cloud running.

Paul: With end-to-end everything.

Paul: To get this to another human.

Edith: Like, you had a team who would build the nice installer.

Paul: Put something in front of a customer. The lifecycle of your product or your service today is a lot shorter than it was a decade ago. The more quickly you can get that feedback loop and act on that feedback loop, the more opportunities you have to learn or succeed.

Edith: Did you say Kafka or Kafkan?

Is this one of the tools that is eventually going to find its way into when you start a project you need an edge deployment tool for machine learning as part of your pipeline as well? And so are we going to see over the next 10 years a sort of an explosion in what we call or what we think of as the One System of what we need to build quickly?

So people try to do things they never could do before, that kind of change, I think, is not going to slow down. Now, I do think on the principle of today's core becomes tomorrow's context, the things that you worry about in terms of where we need to differentiate, where we need to be better, where we need to pick up the best thing, that does change.

I basically think that people aren't going to be arguing about continuous delivery pipeline-

Paul: Sure, the need for CI, the need for feature flags.

Edith: Yeah, it'll just be assumed.

Sam: Today's core is tomorrow's context.

Paul: Far fewer than think they can. One of the significant learnings is that designing good metrics is as difficult as designing good features.

The metrics that you need to drive your business change and you need to be able to respond and adapt at that level of, frankly, business KPIs with this rapidity too. If you look at the Olympics today versus 20 years ago or what have you, you see people doing stuff that no one would've dreamed of. And I think in the case of our industry, it's more dramatic.

Sam: I don't know what the product name will be.

Paul: Sure, sure.

Sam: Or I don't know what mix will be. I do think people will be using services in 10 years that we cannot imagine today. I think that the expectation for what computers will do in 10 years or, computers is a bad word, for what devices will do in 10 years, is wildly different.

Paul: I mean, we still need to do that.

Sam: We'll need to have secure authentication.

Edith: Well, that's what you say as a human.

Edith: Yeah. I mean, that's Terminator.

Paul: I felt like I've read a hundred of these books.

Sam: That's kind of the scary side of it.

Sam: One of the things that put up on the web Devopsassessment.net, and it's a self-service tool to figure out how your performance is and where your bottlenecks are and where you might improve.

Edith: You have to care to even take this.

Sam: Agreed. Okay, so creative destruction is a fact of the way our economy works, right? It is, and I don't mean this as, I don't pretend to be a libertarian, I don't pretend to be a believer that regulation is bad or what have you. But if you take something like the Fortune 100 list or you take any other ranking of companies, the longevity of companies on that list goes down every year.

So they get replaced and value shifts to the innovators. Now, the folks who were trailing behind can say, "We're not bothered by this," or they can say, "We need to change because this is where value gets created." Again, I think there are many points of light in this, where instead of being a victim of change you can be an enabler of change. And my message to people, open your eyes, recognize what you don't know.

There was a great, great, great HBR article and then became a book called Authors were Kegan and Lahey who were, The Real Reason People Won't Change. I think, two Harvard professors in psychology or something like that. Just read the article form from HBR. You don't need the book.

Edith: Yeah, the lack of a decision is a decision.

Sam: Yeah. This is the victim-enabler triangle thing. Are you going to frame the world as a place that does stuff to you, or are you going to frame it as a place where you can do things? And if you just flip that perspective, you'll discover you can do things.

Other people have done things, you can learn from that. You can experiment, you can treat experiments not as things from which you fail but things from which you learn.

Paul: Yeah, that is wonderful.

Edith: Any final, final thoughts, Sam?

Sam: Thank you for having me.

Edith: It's so wonderful to have you.

Edith: It's great to have you.

Deploy code to production now. Release to users when ready. Learn how to separate code deployment from user-facing feature releases with LaunchDarkly.

Topics:
devops ,ci/cd ,continuous delivery ,continuous integration

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}