Tag: continuous delivery

  • Pulumi Deepens Cloud Ties to DevOps

    Pulumi Deepens Cloud Ties to DevOps

    Pulumi has made available a framework for automating the management of multiple cloud computing platforms using familiar programming languages such as JavaScript, TypeScript, Python and Go.

    Company CEO Joe Duffy said Pulumi 1.0 provides a framework that enables developers to automate the deployment of applications on public clouds in a way that eliminates having to learn another programming tool or manually employ YAML files that are often at the root of misconfiguration issues. Pulumi also provides access to a software development kit (SDK) through which scripts or code developed for Terraform, CloudFormation, Azure Resource Manager, Kubernetes or Helm can be imported into the Pulumi framework.

    Pulumi also has extended the reach of its automation framework to provide integration with a variety of continuous integration/continuous deployment (CI/CD) platforms including Azure DevOps, AWS Code Services, CircleCI, Codefresh, GitHub, GitLab, Google Cloud Build, Jenkins and Travis. Pulumi also can be embedded with integrated development environments (IDEs) to provide statement completion, interactive documentation and rich error-checking.

    Duffy noted Pulumi also now can be extended to further adoption of best DevSecOps practices. A Pulumi Key Management Service is integrated with the key management tools from Amazon Web Services, Microsoft Azure, Google and HashiCorp. Pulumi also provides role-based access controls and integration with identity management tools spanning GitHub, GitLab, Atlassian, Active Directory, Okta and Google G Suite, among others.

    Pulumi comes in three flavors: A free Community Edition enables individuals to manage their cloud environments, a commercial Team Edition adds support for organizations and an Enterprise Edition provides additional identity options, policies and controls, as well as self-hosting capabilities.

    Duffy said frameworks for automating application deployments on multiple clouds are necessary because enterprise IT organizations now routinely embrace multiple clouds. Rather than requiring IT operations teams to master programming environments, Pulumi makes it possible to shift deployment responsibilities on to the developer, he said, noting that approach should significantly increase the rate of speed at which applications can be deployed using cloud platforms such as AWS, Azure, Google Cloud Platform, Digital Ocean or others.

    While a lot of progress has been made in terms of continuous integration, organizations are finding continuous delivery to be a challenge. Pulumi is betting that by directly involving more developers in the deployment process, organizations will find it easier to extend their DevOps processes in a way that doesn’t require anyone to learn new programming tools.

    In the meantime, the rate at which new applications are being built is only going to accelerate. As development teams embrace a wide range of cloud-native technologies, it’s only a matter of time before the application deployment backlog increases significantly. IT leaders are going to be under a lot of pressure to solve that issue in a way that results in more applications not only being deployed on a timely basis but also deployed reliably. Having more applications running in a production environment that winds up having issues later isn’t necessarily progress. In fact, it’s likely most IT leaders would find themselves in even hotter water for exacerbating cloud security issues that already plague most organizations.

    — Mike Vizard

  • CircleCI Extends CI/CD Reach to Windows Platforms

    CircleCI Extends CI/CD Reach to Windows Platforms

    CircleCI today announced it will make available its continuous integration and continuous deployment (CI/CD) platform available on a variety of Windows platforms.

    Matt Wyman, vice president of product for CircleCI, said the decision to support Windows stems from recent Microsoft DevOps initiatives, most notably its move to acquire GitHub. As Microsoft invests more time and energy promoting best DevOps practices, demand for CI/CD platforms running on-premises or in the Microsoft Azure public cloud will escalate sharply, said Wyman.

    The Windows environment on CircleCI also includes support for Docker Engine – Enterprise for Windows workflows and all Windows jobs run isolated on a virtual machine. Each new job uses an environment that gets created just in time and gets destroyed once the job finishes running. That approach is intended to ensure both build reproducibility and the security of the code, data and secrets stored in a CI environment. All CircleCI features such as caches, Workspaces, approval jobs and Contexts are now being made available for Windows jobs.

    Wyman said CircleCI now expects organizations to extend the same software development lifecycle processes for building and deploying both Windows and Linux-based applications. The ability to leverage the same pipelines within the context of a common CI/CD platform spanning both environments will help narrow the time and effort required today to build Windows applications, he added.

    Currently, it’s unclear whether a common set of processes for building and deploying applications in Windows and Linux environments might foster greater collaboration within IT organizations. Linux and Windows teams don’t tend to interact much. However, as more organizations look to apply repeatable processes that enable them to build more reliable software faster, the need to standardize DevOps processes has become apparent. Of course, Circle CI isn’t the only provider of a CI/CD platform looking to take advantage of that emerging hybrid cloud computing opportunity.

    It’s also worth noting that providers of platforms such as Microsoft and Red Hat are also promoting their own approaches to software development lifecycle management. Organizations need to decide how much they want to rely on the tools and processes made available by platform vendors instead of a CI/CD platform that integrates DevOps processes across multiple platforms. To fight that battle, CircleCI last month revealed it has raised another $53 million in funding. At that time, the company noted that the total monthly job count on its platform stood at 30 million, up from 7 million in January 2018.

    Regardless of the path chosen forward, organizations increasingly need to build and deploy software on multiple platforms. The challenges associated with managing those processes are nothing less than considerable. The issue IT leaders will need to determine first is how much they want to drive unification of software development from the top down versus simply providing a common set of tools and platforms that their teams will (hopefully) gravitate toward.

    — Mike Vizard

  • Armory Looks to Drive Enterprise Adoption of Spinnaker

    Armory Looks to Drive Enterprise Adoption of Spinnaker

    Armory this week committed to advancing adoption of the open source Spinnaker continuous delivery (CD) platform in enterprise IT environments after revealing it has raised an additional $28 million in funding.

    Company CEO Daniel Odio said Armory will add proprietary tools to a curated distribution of Spinnaker that will make it easier for the average IT organization to deploy and manage Spinnaker. Developed by Netflix, Spinnaker is gaining traction as a CD platform in the wake of becoming one of the four projects being managed under the auspices of the Cloud Delivery Foundation (CDF), an arm of the Linux Foundation.

    Spinnaker is designed to be a CD platform that includes all the management tools required to manage that process. While continuous integration/continuous deployment (CI/CD) platforms such as Jenkins have addressed aspects of CD, most of the daily usage of those platforms has been squarely focused on continuous integration. As part of an effort to meld CI/CD platforms and Spinnaker, the CDF has accepted both Spinnaker and Jenkins as part of the first four projects that will be developed under its auspices. The other two are Jenkins X, a CI/CD platform specifically designed for building microservices-based applications on top of Kubernetes, and Tekton, a set of pipelines also designed specifically for Kubernetes.

    Odio said there are already more than 500 organizations using Spinnaker, and each one is not standardized on a specific CI/CD platform. Armory is part of the CDF but also sees a need for a curated instance of Spinnaker that is optimized to meet the needs of enterprise IT environments, he said.

    In general, Odio said a “flywheel effect” manifests once an organization launches roughly its eighth project using Spinnaker. From that point on, adoption of Spinnaker starts to accelerate to the point where an organization sees the need to standardize on a single curated instance of Spinnaker, he said.

    The bigger issue as far as adoption of Spinnaker and other DevOps tools remains cultural, Odio added. Many organizations still don’t accept the fact that CI/CD platforms are intended to foster a level of accelerated development that makes it more feasible to experiment and innovate. There are, of course, inherent risks to that approach in the sense that many of those projects might fail. Many enterprise IT organizations are still coming to terms with the need to accept higher levels of failure as the price of learning, he noted.

    In the meantime, many organizations that have embraced DevOps now find themselves on the cusp of a major transition as the shift toward cloud-native applications increases. Most CI/CD platforms today were designed to accelerate development of monolithic applications. Now what’s needed is a new generation of CI/CD platforms that are designed to accelerate development of microservices-based applications based on containers. As a result, many organizations will end up employing multiple CI/CD platforms. Armory is betting many of them will try to delineate where CI leaves off and CD begins.

    — Mike Vizard

  • DevOps Chat: Armory Discusses $28M Funding, Continuous Delivery

    DevOps Chat: Armory Discusses $28M Funding, Continuous Delivery

    The tribe at Armory announced the company‘s $28m series B funding, led by Insight Partners. Armory enables continuous software delivery at enterprise scale, powered by Spinnaker.

    That is a crisp mission statement, but beyond that Armory is bringing the open source Spinnaker to the enterprise market. As such, they are also helping the entire Spinnaker community and as part of this the entire CD market. They are members of the CD Foundation and part of the Linux Foundation as well.

    In this DevOps Chat, I had a chance to catch up with Armory’s founder/CEO, DROdio and VP of marketing, Carl Landers to talk about Spinnaker, CD and the state of software delivery.

    BTW, if you are interested in learning more about Spinnaker and will be in San Diego for CloudNative.com/KubeCon, the Spinnaker Summit is the weekend before. The Armory folks have been nice enough to arrange a 20% discount if you would like to go:
    www.eventbrite.com/e/spinnaker-sum…=ARMORYAUGUST20. The code for discount is ARMORYAUGUST20.

    Also, you can join the Spinnaker Slack channel at: join.Spinnaker.io

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. We’ve got some exciting funding news on today’s DevOps Chat. A company I’ve been familiar with now for a few months, Armory, Armory.io—is it Online Networks, DROdio, or just Armory?

    DROdio: Just Armory.

    Shimel: Armory. And—well, they let that cat out of the bag. I’ve got with me the Armory CEO and Founder, DROdio. DROdio, welcome.

    DROdio: Great to be here. Thank you, Alan.

    Shimel: And some people, if you’re wondering out there, when I first met DROdio, he told me it’s like rodeo with a D, so if you’re wondering how to say it, that’s how you say it. But DROdio, just for the record, give our listeners your real name, your full name.

    DROdio: Yeah, so, my full name is Daniel Rubén Odio, and I go by DROdio. It’s my handle on everything, so DROdio is easy.

    Shimel: Okay. And then joining DROdio and myself today is—well, DROdio, why don’t you introduce Carl?

    DROdio: Sure. I’m very happy to welcome Carl to Armory. Carl has recently joined us, our VP of Marketing. Carl, I’ll let you introduce yourself.

    Carl Landers: Welcome to everyone who’s listening. This is Carl Landers, and I’m happy to join you, and I’ve been with DROdio at Armory for a couple of months, and we are excited to share news today about what’s happening with Spinnaker and with Armory. Alan, it’s great to be here.

    Shimel: Thanks, Carl. Hey, and it’s a pleasure to have you here. So, we’re gonna jump into Spinnaker and Armory and go a little bit more in depth in that in a moment, but let’s take care of the news first. The big news is, you’ve announced a series B of $28,000,000.00, and it’s led by Insight Partners, correct?

    DROdio: That is correct. Very happy to have Insight joining our board. Insight has seized the same opportunity that we do, which is that there is a large category forming in software delivery that could never be a category before, and we can talk a little bit about why that’s changing, but Lonne Jaffe is gonna be joining our board as the newest board members, and I just—I couldn’t be more thrilled about having Insight involved and funding Armory’s growth.

    Shimel: Well, and again, let me just fill in with a little background. For those who may not be familiar with Insight Partners, I think the number is something outrageous, $25,000,000,000.00 under management or something like that. And they are the folks who have really financed a ton of, or a bunch of really blue chip companies in the DevOps space, including companies like JFrog and Tricentis and now Armory, and more than several others, really doing a nice job there.

    Lonne Jaffe from Insight is joining the board, you mentioned, DROdio. Any just—I mean, do you know his background that you can share? What does he bring?

    DROdio: Yeah, so, Lonne is an especially good board member for us, because Lonne has a deep background in AI and ML and really understands that space well. And Alan, I’m sure that you know this and probably the people listening also understand it—software delivery is, especially into the cloud, is just in the first innings of a very long game. So, really, a lot of what’s happening today is focused more around automation.

    And, in that process, as software delivery matures, we see a lot of opportunities to really make it smarter and unlock a lot of data across the SDLC. So, having Lonne on the board just positions Armory extremely well to be a leader in that over the coming decade. So, very happy to have him involved with that deep level of expertise.

    Shimel: Absolutely. We’re gonna dive more into that as well in one second. Just, last question or last point I wanted to make regarding the announcement—you know, Insight led this round, I take it, but you also have some pretty nice names on your investor list even prior to this, right, if I’m not mistaken?

    DROdio: Yeah, we’ve been very blessed. You know, we started in Y Combinator’s W17 batch and we’ve had Noah Doyle from Javelin was our seed investor, Crosslink with a series A investor, Celeal from Bain has participated in a number of rounds. So, we also recently had Robin Vasan from Mango join as an investor as well.

    So, we just—you know, we were lucky to have a lot of great angel investors, including Eric Reese, the kind of father of the lean startup series; Andrew Miklas, a founding CTO of PagerDuty; and other angels like that. So, you know, we just—we’re in a bit of a special situation with Armory. We just, we’ve never had a hard time fundraising. I think a lot of that has to do with just this massive shift of computing into the cloud and all the challenges that come along with it.

    Shimel: Yep. Alright. We covered the announcement well. I think we did it justice. Let’s dive in now, guys. So, look—when you talk about Armory, you can’t talk about Armory without talking about Spinnaker, right? And again, in our audience—well, our audience is pretty savvy to this stuff. They probably have heard of Spinnaker. Spinnaker, of course, came out of the Netflix kind of factory there that brought so much great software tools to the forefront. But it was also—you know, Spinnaker was the father of, I mean, if Netflix was the father of Spinnaker, Google is the godfather. And, you know, they’ve done a lot for us.

    But I’m not giving it justice. DROdio, you’re much more well versed on Spinnaker. Carl, I don’t know how much of the Spinnaker story you know, but guys, give us the background.

    DROdio: Yeah, sure. Why don’t I—before we talk about Spinnaker, actually, let’s just talk about some of the trends that we’re seeing in computing and then back into how Spinnaker is solving for some of that.

    So, you know, we’ve been working with large enterprises, Fortune 500 and Global 2000 enterprises. And what we’re seeing—and I don’t think this will be a surprise to anybody who is deep in DevOps—is, enterprises are recognizing that, in order for them to thrive over the next decade, they really have to become software companies. Now, they may not die. They may just survive. But in order to really thrive, they have to make big investments, and their ability to take an idea and get it out into the world with safety and velocity—so, to really become good at navigating the SDLC, the software development life cycle.

    The big shift that we’re seeing is that companies are starting to move out of data centers and into the cloud, and what we’re seeing is—and I actually don’t think that every engineering leader is quite seeing it this way yet, but what we’re seeing is that a company’s path to production in a data center was a very static one. It didn’t change. Maybe they were running The Sphere. But they could afford to build it themselves, and they had to build it themselves because every data center’s different.

    And so, they would use these, what we would consider legacy kind of mutable configuration management tools like Chef and Puppet and Ansible to build these brittle paths into production, into their data centers.

    Well, that’s changing. The infrastructure layer is going from being very static to very fragmented, and we think that’s just beginning. There’s so much innovation coming from Amazon and Microsoft and Google that large enterprises, which have been building their own roads into production, are having a hard time dealing with this dumpster fire of innovation that’s coming from the cloud. I mean, if you look at AWS, it’s more than just AWS, it’s EC2, it’s ECS, it’s EKS, it’s Fargate, it’s Lambda—it’s whatever AWS is gonna announce at re:Invent in November. And, you know, that’s just AWS, let alone GCP or Azure or Pivotal or Oracle.

    And so, you know, when I talk to CIOs at Fortune 500 companies, they have a big problem, which is that they have these legacy and brittle paths to production that are not set up to enable them to really take advantage of this just massive amount of innovation that’s happening in the cloud. And so, they have a hard time actually getting their ideas out as features into the cloud.

    Netflix, as it started moving out of data centers and into the cloud a decade ago, recognized that there was a need for a platform that would not only codify the process of going from idea to featured production—so, that’s really all of the kind of human and cultural aspects of writing code and getting it out into the world. So, things like different stages. So, manager approvals, different environments, Dev/Stage/Prod, code scanning, vulnerability scanning—all of those things, security policies, compliance policies codify all of that into one golden path, but then also allow a company to have workload portability. So, allow a company to be able to decide if that code should go in as a VM on AWS or into a data center running Kubernetes.

    And so, they built Spinnaker to become much more sophisticated about really leveraging all of those different cloud targets. And so, now, they’re giving it away, right? Netflix and Google have codified the kind of decade of best practices they have at delivering software into the cloud, and they’re giving it away to anybody that is serious about becoming a software company.

    And so, that’s the real big opportunity that we see is to bring this open source project that codifies these best practices into Global 2000 and Fortune 500 companies that are serious about being able to thrive and not just survive over the next decade.

    Shimel: Absolutely. And a couple things there, right? As widespread as open source adoption is—and it is, it’s 95 percent penetration or higher—Global 2000 and Fortune 500 companies, when they do adopt open source, especially something platformish like Spinnaker, want to have some commercial entity usually wrapped around there, someone who’s gonna help provide support, and someone to go to if there’s a problem, someone who’s gonna continue kinda pushing the ball forward in terms of development. And that’s a role, right, that Armory is sort of fulfilling in the marketplace—the commercial Spinnaker.

    DROdio: Absolutely. Very much so. So, there’s a couple things about that. Spinnaker—I mean, if you think about what a company needs to do to become software first, the entire way they deliver value to the world is with some sort of platform either that they’ve built and housed, which is usually the case. They’ve extended Jenkins, which is really a CI tool, into delivery because they had to. But that’s really the entire way that they deliver value into the world is by being able to take code and get it out with safety and velocity.

    And so, when a company is starting to think about Spinnaker, I mean, that is like doing open heart surgery on a company’s core ability to create value. And Spinnaker is a huge and heavy code base. I mean, it is a big, meaty project. And so, companies need a lot of assistance and best practices and support to be successful with Spinnaker, because it is like open heart surgery for them.

    Now, the good news is that Armory is very, very good at doing this. So, we have the most expertise operationalizing Spinnaker inside complex enterprise environments and making it work within these complex environments of any company. As Netflix once joked with us, they only ever operationalized it once, right? We’ve done it many times.

    We’ve also built a number of features that are enterprise grade to make Spinnaker more consumable and valuable to the enterprise. So, things like being able to install it in an air gap data center environment, or pipelines as code that gets into this GitOps need of being able to create these pipeline definitions and then check them as code to make them reusable and make pipelines more standard across teams.

    So, there’s all sorts of features that we have built in our building that extend Spinnaker for specifically enterprise needs. But most broadly, what we are really doing is, we are championing Spinnaker and helping the enterprise adopt it so that they can become, truly, software first in a very sophisticated, multi-cloud way.

    Shimel: Absolutely.

    DROdio: One other thing that I would mention is really the cultural change that’s required from these large enterprises, which is probably its own separate podcast and conversation, but there’s this thing that we see in these Global 2000 companies, which is that most companies are not very good at managing risk in production in sophisticated ways. And what I mean when I say that is, most of these Industrial Age companies are used to building products or having services that must be perfect in production. When you’re building a car, you can’t have it come off the assembly line and fail right away.

    The kind of cosmic joke is that the slower you are when you’re writing code, the less safe you become, and by moving faster, you actually become safer. But that’s a terrifying cultural concept to these companies that don’t wanna break customer trust or damage brand equity in production.

    A platform like Spinnaker allows them to become much more sophisticated about managing risk in production. So, things like a canary deployment allow companies to not nuke their entire user base when they ship a new feature. They can, instead, limit the blast radius. And so, it’s an important cultural element here to bring a platform like Spinnaker into the company to give, really, the executives and management the kind of license and the trust to start to innovate faster and to move faster in ways that allow them to feel safe, but then become much more sophisticated about the way that they manage risk.

    So, there’s a whole cultural aspect to Spinnaker that is very necessary to give companies these tools that they need to actually undergo this digital transformation.

    Shimel: There’s a cultural aspect to everything with DevOps, even.

    DROdio: Yeah. [Laughter]

    Shimel: But let me—hey, Carl, we’ve been negligent, here. Let’s bring you into the conversation. So, Carl, it’s a unique kind of opportunity. It’s almost a double-edged sword, though, in that, you know, you get to, you’re in charge of marketing what, in essence, is this fantastic platform, Spinnaker, and then, on top of that, what Armory is doing to enhance and make it better for large organizations to adopt Spinnaker—you know, it’s a great opportunity, but it’s a little scary it’s that big.

    As newly appointed or here a few months now VP of Marketing, what do you see as the challenge here in going to market?

    Landers: Sounds like you’ve been living in my office, Alan, the way you just laid that out. But, you know—yes, it’s a big challenge. The way we look at it, though, I think is fairly straightforward. We’re devoting our resources to making Spinnaker a success. As the Spinnaker community grows, as more people are aware and are using and are having success with Spinnaker, the right number will come to Armory for help when they need it.

    And so, as the marketer at Armory, my focus is, the majority of my effort is—how do we make Spinnaker a success? How do we grow awareness and use of Spinnaker so that more organizations are experiencing the benefit? We know that we’ll get our fair share. So, marketing Armory is important, but top of mind for all of us here is making sure Spinnaker is a big success. Does that make sense?

    Shimel: Makes perfect sense. And we would be negligent if we didn’t mention this in that regard that, I guess it was now about six months ago, maybe eight months ago, both Netflix and Google joined what’s called the CDF—Armory as well—joined the CDF, the CD Foundation, which is a sister organization to Cloud Native Computing Foundation, all under the auspices of The Linux Foundation. And, you know, we talk about a community and we talk about making Spinnaker successful—that has to, I guess, play into it.

    How big a role do you see the CDF playing into this, guys?

    DROdio: Carl, I’ll be happy to let you start there and then I can add some color, if you’d like.

    Landers: Sure, happy to. Well, we are a proud member of the CDF along with the other organizations you mentioned, and there are several projects in there, including Jenkins and Jenkins X and Tekton and Spinnaker. And the CDF is forming up nicely and we’re contributing to that foundation and helping it take off, and it is gonna be a great way to help build the community around all of these projects, Alan.

    One of the things that’s gonna be a great addition to the community is, we have a new developer, evangelist, open source leader joining Armory, Dee Kumar. Dee was actually doing this job for the CNCF and for Kubernetes. So, super experienced about how to grow a successful open source community and market effectively, and she did that at the CNCF and is coming over to join Armory on Monday to help us and help the CDF repeat the success of Kubernetes with Spinnaker. So, that’s super exciting.

    Shimel: That’s great. That’s big, that’s big. DROdio, do you want to add—you said you wanted to add a little color?

    DROdio: So, you know, I spend my day talking to Fortune 500 CIOs, CTOs and what I’m really seeing is that DevOps is something that I think executive suites at large companies have considered to be tactical, and it really hasn’t been—it hasn’t risen up to the level where a CIO or CTO or even a VPM just is so focused on it.

    That’s really changing. As companies realize that they must become software first to compete, DevOps is becoming much more strategic, and I believe that CIOs are going to have to own it personally and be very involved in the cultural change that’s required to transform their companies into ones that become very good at getting through the SDLC in minutes instead of months.

    And that’s really why we created Armory. The reason Armory exists is to align very closely with the needs of Global 2000 enterprises that re committed to that transformation and that want to invest in sophisticated, modern platforms like Spinnaker to enable that. We see Spinnaker as powering the core of our platform as we build it. Spinnaker really solves for the delivery challenges that companies have.

    There’s a lot more to the SDLC than just delivery, and so, we are really making a big bet on Spinnaker while having an eye towards the needs of the CIO and solving for all those other blockages in the SDLC that a company has that slow them down.

    So, Spinnaker is just this incredible platform that we’re putting at the core of our strategy and our platform as Armory grows and matures. And the first thing that Carl said is to cement its status as the de facto standard for Cloud Native software delivery. And then also, having all the major cloud vendors contribute and be involved has been a huge step for that as well. So, I think it’s becoming very obvious that, if a company’s really serious about moving workloads into the cloud, Spinnaker is the way to do that at scale.

    Shimel: Excellent. Absolutely. Guys, we’re running low—we’re way over time at this point. I did want to just mention or bring out a few other things, and Carl or DROdio can answer this. In terms of references, we’re talking Fortune 500, we’re talking Global 2000—can you give us some examples of organizations that are using Spinnaker? And if they’re using Armory a well, great, but you know, just to kind of bring home that message of the kind of organizations that are relying on Spinnaker.

    DROdio: Sure. So, on the Spinnaker.io website, which is the project site, there are a number of companies that are publicly listed that are using Spinnaker. Companies like Cisco and Target and Under Armour and Samsung and others. There are actually several hundred enterprises using Spinnaker that are not publicly using it, but are making big bets on Spinnaker. And there are also many enterprises that are using Armory specifically. And so, those include some of the world’s largest technology companies, some of the world’s largest banks, some of the world’s largest health care companies.

    So, we are very dedicated to ensuring their success with Spinnaker. We believe that Armory is the best way for a company to be successful with Spinnaker. But more broadly, we’re also really working hard as deep contributors to the open source project to make Spinnaker very consumable, easy to onboard, easy to self-run POCs and get very quick time to value.

    So, there’s a lot of focus, like Carl said, with the series B in really making Spinnaker easy to try and easy to be successful with as an open source project, and then making it very enterprise grade and bulletproof for enterprises that are putting it at the core of their hybrid and multi-cloud strategies.

    Shimel: Excellent. Excellent, excellent. I know—again, just one more thing and then I’m gonna call it a wrap. There is, as part of CloudNativeCon and KubeCon, there’s a Spinnaker and CDF. Well, there’s both a CDF and I thought a Spinnaker Con coming up in San Diego.

    DROdio: Yeah, Carl, why don’t you talk a bit about that, because I think there’s a few opportunities for people to get involved.

    Landers: Absolutely. So, Alan, I think you’re referring to the Spinnaker Summit which is coming up. It’s going to be collocated with KubeCon in San Diego. It’s taking place on—let’s see if I get the dates right—November 16th and 17th, so over that weekend, and then KubeCon starts on the Monday, Tuesday following. So, it’s gonna be a huge Cloud Native fest in San Diego.

    We were just reviewing the CFP, the proposals that came in today. There were, oh, 80 or 90 sessions submitted from amazing companies to speak at the summit, and we’re just going through right now and picking the best ones to actually put on the agenda. It’s gonna be a great event and information is available from the Spinnaker.io website. You can get there and learn all about the Spinnaker Summit. Thanks for the plug.

    Shimel: Absolutely. And you know what, when it’s live, we’ll try to get some announcement—when the CFP is live, we’ll get an announcement out.

    DROdio: And, hey, Alan? We haven’t talked about this yet; Carl, we haven’t talked about this yet, but why don’t we just go ahead and offer something up, here, because we do have a culture of defaulting to action.

    Why don’t we create a discount code for anybody who’s listening to this podcast and would like to attend the Spinnaker Summit and maybe we can make it devopsy.kinsta.cloud or something like that—

    Shimel: Fantastic.

    DROdio: – and Armory will provide a bit of a discount for anybody who would like to attend to help anybody who’s listening convince their manager that it’s something worth going to. So, I don’t know how much of a discount we can provide, but I’m happy to commit to doing something.

    Landers: Absolutely.

    Shimel: Thank you very much, DROdio. And you know what, for listeners—take advantage of it. Guys, what I’ll try to do—Carl, if you can get me the details and the code, I’ll include that in the show notes for the podcast, and anyone listening to this can go check it out there as well as, it’ll be in the devopsy.kinsta.cloud article for it, as well.

    DROdio: Perfect.

    Landers: Sounds good. I’ve got DROdio’s credit card number coming over to you.

    DROdio: That’s right. [Laughter]

    Shimel: [Laughter] Fantastic!

    DROdio: And then, also, for anybody who would like to learn more about Spinnaker, there is a Slack workspace, and I would highly recommend that anybody check that out. You can get to it on the Spinnaker website, but you can also just go to Join.Spinnaker.io and enter your e-mail address and then you’ll be in that community.

    There’s over 7,000 people in there, and it’s a very active community. We are very active in there, as is Netflix and Google and many others. And if you—you know, it’s a very friendly community, so if anybody would really like to ask questions, don’t be afraid to ask any newbie questions in there, we’ll be happy to answer them.

    Shimel: Fantastic. Guys, I gotta tell you, this was the longest 15-minute interview I’ve ever done.

    DROdio: [Laughter] And yet the shortest at the same time, feels like. [Laughter]

    Shimel: Yeah. I told you, it goes quick. I apologize, but you know what, I think it was well worthwhile. First of all, guys—congratulations on the series B. You know what? In today’s world, it seems every day some company’s announcing funding, but there’s a lot of entrepreneurs out there, and DROdio, you know this, right, who never get to raise money.

    DROdio: Yeah.

    Shimel: They try and try and try and they just can’t get it done. And the fact that you guys are doing it is a testament to both Spinnaker and Armory’s plan as well as what you’re doing, so, congratulations—and to you guys individually—so, congratulations and success.

    And then, secondly, we’re excited to see Spinnaker take its place in the CD universe, here.

    DROdio: Yeah, likewise. Thank you for the support, Alan, as well.

    Shimel: My pleasure.

    Landers: Thank you, Alan.

    Shimel: Hey, alright—DROdio and Carl Landers from Armory announcing their series B, and it’s all about Spinnaker and Armory here today. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • Game On: Gamification for the Win

    Game On: Gamification for the Win

    Staying competitive in today’s fast-moving digital economy is easier said than done. Operating in a digital environment requires a significant shift in company culture and an agile software environment that accelerates time to value. Creating a DevOps environment helps companies keep pace, but it requires a workforce that is empowered, excited and motivated.

    Gamification offers a unique opportunity to continuously engage your workforce by applying game-design elements and game principles into a corporate setting, making work more fun. Companies can develop a team-oriented Pod model that incorporates gamification to improve employee engagement and productivity, enable team members to work more efficiently, accelerate the learning curve and deliver more sophisticated products to market faster.

    When I joined Cognizant Softvision as CEO, I wanted to empower our teams and promote a continuous delivery mindset by developing a delivery model that was customer-centric, differentiated and unique to each client without being prescriptive. Thus, Game of Pods was born.

    The global, Game of Pods gamification program is designed to provide timely and superior customer service. At a high level, Game of Pods inspires and measures team performance and delivery while encouraging and monitoring individual performance. During competition, the Pod and its members are recognized and rewarded for their collective and individual contributions with badges and trophies.

    We typically focus on the output of each pod, rewarding collective behaviors and achievements that help the pod reach higher efficiency and quality targets. Collective badges are awarded to the pod while personal and peer-to-peer badges are awarded to the pod members. Pod badges are earned as a team and are focused on the health of the project, performance of the pod, quality of delivery and alignment with client objectives. A leader board displays the badges each pod earns, their experience points and their trophies. Pod and individual recognitions are celebrated over email and across Facebook Workplace, and shared with all employees.

    While perhaps not as intense as “Game of Thrones,” Game of Pods is the epitome of gamification in action and enables organizations to reach a higher level of efficiency and professionalism while challenging employees to achieve personal goals in a fun, team-oriented process. In addition, Game of Pods offers other benefits such as:

    • A flexible model that can work in any client environment.
    • Team empowerment that incentivizes teams and individuals to achieve more.
    • An approach that encourages diverse thinking that recognizes and rewards teams and individuals for improvement.

    Game of Pods is most effective in organizations that embrace an agile mindset and understand the need for flexibility in today’s fast-moving environment. While gamification has come a long way, successfully incorporating it into the workplace can be challenging. However, integrating gaming into your organization can empower and excite employees, motivating them to overcome obstacles that might otherwise stand in the way of success and sustainable innovation.

    — Andres Angelani

  • How Continuous Testing Advances Your Business Goals

    How Continuous Testing Advances Your Business Goals

    The goals of any successful business fit into two broad categories: driving higher revenue and greater operational efficiency. Finding solutions to achieve both of these is an organization’s goldmine.

    Considering the ease of access to new, alternate products from developers across the globe, competition continues to grow. In the software industry, customer expectations magnify cut-throat competition. Users expect newer features, faster releases and ever-improving optimal performance.

    To achieve these core business goals, DevOps teams now develop software with a mindset of continuous delivery. This practice helps organizations achieve faster release cycles while delivering newer features to meet customer demand.

    For most teams, there remains a major ongoing challenge: effective testing within this high-speed delivery cycle. Traditional (non-automated) testing methods became a bottleneck in the CI/CD pipeline mindset, forcing organizations to choose between quality and speed to market.

    Continuous testing helps overcome this problem by weaving testing throughout the delivery cycle by leveraging automation. But what tests should be automated?

    In late 2018, KMS surveyed 135 professionals who successfully implemented continuous testing, for their insights on the process. Of the organizations surveyed, the following tests were always automated:

    • Unit tests (47.4%)
    • Component tests (46.7%)
    • Integration tests (45.9%)
    • UI tests (38.5%)
    • Performance and load tests (57%)
    • Security tests (52.6%)
    • User acceptance tests (34.1%)

    We also found the top three focus areas of test coverage for continuous testing were:

    • Integration tests (55.6%)
    • Security tests (48.1%)
    • UI tests (43.7%)

    As a bottom line, businesses must successfully adopt continuous testing to keep their delivery pipelines in sync with development.

    Despite several benefits arising from continuous testing, KMS found a few challenges for organizations that have adopted this methodology. Seventy-eight percent reported that continuous testing would have been easier to adopt with a directive from their executive leadership.

    What’s more, 78% indicated they would have liked more team ownership of the initiative and 86% would have liked better team collaboration.

    So, how do organizations get executive buy-in and rally the team to adopt the practice? By understanding and communicating how continuous testing directly contributes to achieving the two key business goals of increased revenue and operational efficiency.

    Let’s drill down into increased revenue generation. After all, money is what keeps any business in motion. Businesses drive revenue by:

    1. Solving a pain point for customers.
    2. Encouraging users to adopt their solution.
    3. Having the agility to shift and meet changing consumer needs, with speed.

    To achieve operational efficiencies, businesses focus on:

    1. Achieving shorter release cycles.
    2. Receiving feedback and ability to respond with agility.
    3. A more effective team, without increasing headcount.

    With these goals in mind, there are three core business cases for adopting continuous testing:

    Increased Agility and Confidence in Quality

    Agile is the ideal delivery model for all software companies. True agility means organizations can shift focus quickly and respond rapidly to customer feedback or changes in the market. It also gives teams the freedom to explore new opportunities/solutions. Continuous testing enables this agility by supporting a shift-left philosophy that uses test automation in the earlier stages of the development cycle. Shifting left enables a continuous feedback loop that allows teams to respond to defects and establish better team communication.

    By adopting continuous testing, 80% of professionals found fewer defects escaping to production. Reacting to feedback quickly allows companies to give customers the products they want. An organization can increase revenue by delivering market-disrupting features.

    Automation tools also encourage a testing mindset in developers—80.7% of companies adopting continuous testing have found their developers doing more testing. This mindset shift is critical to achieving agility with better collaboration. It makes the quality of the software the responsibility of the entire team, truly aligning with the Agile Manifesto. As a result, product quality and user experience benefit, and happy customers increase revenue.

    Faster Overall Speed

    Keeping up in today’s market requires shorter release cycles. As I mentioned earlier, adopting continuous testing enables faster sprints by eliminating the testing bottleneck at the end of the delivery life cycle. In fact, 83.7% of companies have achieved shorter release cycles by adopting continuous testing.

    Speeding up the software development life cycle pushes products to market faster. Getting features in the hands of customers before your competition gives your company a huge competitive edge. By adopting continuous testing, companies are not slowed down by antiquated testing initiatives. Speed enables them to compete on a global scale and disrupt the market.

    Lower Operational Expenses

    How do you balance speed and cost? Automation. Continuous testing automates routine tests. By using open source tools such as Katalon, teams can automate with minimal extra expense. This not only helps you test faster, but your team can be more productive—84.4% of companies have achieved better test coverage with the same team size and 67.4% were able to test with smaller teams. Either way, you get more done without investing in additional overhead.

    However, automation is not here to replace testers. Automation in pre-production environments gives your resources the bandwidth to work more strategically: 53.3% of companies that have implemented continuous testing don’t test manually in pre-production environments. Seventy-four percent now have the bandwidth for exploratory testing in production. Use your team and resources where they are most effective, doing the work automation can’t. Ultimately, smart use of resources achieves a sought-after balance of speed and cost.

    By exploring the business cases for continuous testing, companies achieve true agility. The methodology seamlessly aligns with fundamental business goals. Enabling continuous delivery, continuous testing will support revenue growth and operational success for your organization.

    — Mush Honda

  • Pivotal Embraces Spinnaker for Continous Delivery

    Pivotal Embraces Spinnaker for Continous Delivery

    Pivotal Software has added support for the Spinnaker continuous delivery platform to its platform-as-a-service (PaaS) environment for the open source Cloud Foundry PaaS.

    Richard Seroter, vice president of product marketing at Pivotal, said version 2.6 of Pivotal Cloud Foundry (PCF) extends the reach of the Spinnaker CD platform developed by Netflix to its PaaS environment and Enterprise PKS, an instance of Kubernetes curated by Pivotal and its sister company, VMware.

    At the same time, the latest version of PAS adds support for a beta instance of custom sidecar processes, which enable developers to embed additional functions running in an isolated container directly within their applications. That capability makes it possible to deploy, for example, a service mesh within the application, said Seroter.

    Finally, Pivotal plans to add multicenter replication capabilities for MySQL databases and a permissions model to Concourse for PCF, a continuous integration tool for building application pipelines with a Pivotal CF environment. That latter capability provides a mechanism through which DevOps teams can automate application updates, including patches, end to end, Seroter noted. As more patches are released to address the growing number of critical flaws involving microprocessors that make use of hyperthreading, the ability to automate their deployment is now more critical than ever, he said.

    Pivotal is seeing the deployment of both traditional 12-factor applications and more modern containerized applications on its PaaS environment. At the same time, the Cloud Foundry Foundation, which oversees the development of the Cloud Foundry PaaS, has,  via Project Eirini, made it possible to deploy containers that rely on Kubernetes rather than the Diego orchestration platform developed for Cloud Foundry. However, Eirini is still an alpha project and Pivotal has not yet fully committed to a specific level of support for Kubernetes with its overall PaaS strategy.

    In the meantime, Seroter said PCF continues to gain momentum in organizations looking to build and deploy software much like a technology company. As more organizations realize how dependent they are on software to drive revenue, they want to rely on a platform that makes it easier for them to manage software development and deployment platforms at scale, he noted.

    As part of that effort, Pivotal Software is aggressively incorporating tools that will enable organizations using its PaaS to implement best DevOps process. Many have adopted various modern development platforms in isolation but continue to rely on the Cloud Foundry PaaS to automate the building and deployment of mission-critical applications. Now, two classes of development platforms are merging into a single entity that makes it easier to embrace agile development methodologies using a lightweight development platform.

    Whatever the outcome, PaaS environments are not going away anytime soon. However, what organizations perceive as the role a PaaS environment plays in any enterprise soon might expand considerably as more container technologies are infused into the platform.

    — Mike Vizard

  • Whitepaper – Easily Build Continuous Delivery Pipelines with Jenkins and Pipeline Plugin

    Whitepaper – Easily Build Continuous Delivery Pipelines with Jenkins and Pipeline Plugin

    Easily-Build-Continuous-Delivery-Pipelines-with-Jenkins-and-Pipeline-Plugin

    Organizations have been orchestrating pipelines with Jenkins for years. As Jenkins and continuous delivery experience deepens, organizations want to move beyond simple pipelines and chart complex flows that map to their specific software delivery processes. For Jenkins users, creating and managing complex pipelines just became easier with Jenkins and the Jenkins Pipeline plugin. Learn what it is, what it does for you, and how to set up your delivery pipelines using it.

    Download this whitepaper and learn how you can deliver software at the speed of ideas.

    [su_button url=”https://www.cloudbees.com/resource/whitepaper/easily-build-continuous-delivery-pipelines-jenkins-and-pipeline-plugin” target=”blank” background=”#ef2d3f”]Download Now[/su_button]

  • 27-Factor Assessments Lead to Success With DevOps

    27-Factor Assessments Lead to Success With DevOps

    October 2019 will mark the 10th anniversary of the first DevOpsDays, where the term “DevOps” began to catch on. In the world of information technology, 10 years is a long time and it is quite evident based on the amount of change that has transpired since then. To name a few, we have seen the maturing of CI/CD automation and many innovations such as application release automation, containers, cloud infrastructure orchestration, DevSecOps, DevOps database, DevOps governance and micro-services.

    These innovations have become part of “mainstream DevOps.” This evolution is continuing with AIOps, machine learning, value stream management and others. Each of these innovations has made DevOps not only more powerful but also more complex.

    As a consultant working on DevOps projects through their life cycle, I have learned that complexity can plague the success of DevOps within an organization. Complexity cannot be avoided, as DevOps is complex and will likely continue to be. However, the key to avoiding failure through your DevOps journey is to engage the complexity by using DevOps tenets to implement DevOps. Do not try to boil the ocean. Instead, at each leg in the journey, take inventory of where you are in terms of current goals, state and best practices. Fine-tune your direction and build your solution using proven continuous delivery methods.

    The 27-Factor Assessment Model

    A comprehensive yet efficient assessment of your current state is key for ensuring complexity has not gotten out of hand and the organization is focused on success criteria that meet the needs of the business.

    I use a 27-factor assessment model. The factors are the cross-product of current best practices for three dimensions (people, process and technology) with nine pillars.

    A Scope of the 9 Pillars

    Leadership: Gain insight and understanding of your leadership practices and how leadership can improve DevOps adoption and performance.

    Culture: Identify opportunities to improve cross-functional collaboration and communication across your organization.

    Application Development (or Design for DevOps): A practical analysis of application development practices identifies improvements for your DevOps performance.

    Continuous Integration: Analysis of branching and software integration workflows and tools identifies bottlenecks and improvements for builds and packaging processes.

    Continuous Testing: Analysis of end-to-end software testing, verification workflows and tools identifies bottlenecks and improvements for accelerating testing while improving the coverage and quality of tests.

    Infrastructure on Demand (or Elastic Infrastructure): Analysis of systems and services for orchestrating and hosting applications and DevOps workloads provides insights to improve performance and utilization of resources.

    Continuous Monitoring: Analysis of end-to-end monitoring workflows and tools for applications, releases metrics and infrastructure provides improved visibility for all business and technical stakeholders.

    Continuous Security: Analysis of security practices and tools identifies opportunities to integrate security practices into the continuous delivery pipeline.

    Continuous Delivery/Deployment: Analysis of delivery and deployment practices identifies improvements for safer, faster and more efficient releases.

    Each combination of pillar and dimension has associated best practices used to score relevance and current state relative a DevOps goal agreed by the organization. Here is an example of the continuous security pillar.

    The 27-factor assessment for an application is an important input to a future state value-stream map workshop. The value-stream map is then transformed into a road map and implementation plan.

    This assessment approach is thorough and yields results that are usually accepted by stakeholders because they are involved in the process at each step. The result is aligned to their priorities and goals and the solution road map is directly traceable to stakeholder inputs. The approach is flexible enough to evolve over time and can be customized to suit the priorities of an organization. For those that argue that 27 factors are too many and too complex, I must say the complexity of DevOps itself requires a comprehensive assessment approach.

    Conclusion

    In this article, I described a comprehensive, efficient and evolvable assessment approach that uses 27 critical success factors for assessing DevOps applications. While DevOps offers immense value for software development, delivery and deployment, a rigorous and thorough assessment with up-to-date best practices are essential to accomplish DevOps goals. Each organization is different and has different DevOps goals and requirements. The changes to the three dimensions vary according to the results of each DevOps assessment.

    — Marc Hornbeek

  • 8 CI/CD Best Practices for Your DevOps Journey

    8 CI/CD Best Practices for Your DevOps Journey

    According to a recent IDC study, the worldwide DevOps software market reached $2.9 billion in 2017 and is forecasted to reach $6.6 billion in 2022. With over 50% of organizations embracing DevOps last year, continuous integration (CI) and continuous delivery (CD) have become an integral part of the software development process.

    Your business is likely embarking on a DevOps transformation of its own. In this blog post, we will discuss CI/CD best practices that can help accelerate adoption no matter where you are in your DevOps journey.

    But first, let’s take a step back and set the stage for why we practice DevOps in the first place.

    Shifting left with CI/CD and the promise of continuous everything

    Continuous integration and continuous delivery refers to the process of developing and delivering software in short cycles of build-configure-deploy-test-release underpinned by automation. In short, we do CI/CD to deliver higher-quality software frequently and predictably.

    CI has become practically ubiquitous to software development. Therefore it is not surprise that as the bread and butter of development, CI is a key practice in DevOps organizations.

    CD is not as widely adopted as CI, but is key to shifting left. CD starts with development, building, unit testing, static code analysis (SCA) and static analysis security testing (SAST) on CI. Eventually, the pipeline extends the automation to functional, integration, performance and security testing, along with configuration management and deployment. These are critical areas for automation — and in a DevOps context they are essential.

    I would even make the jump and say that if you aren’t doing CD, you aren’t doing DevOps well. Why? Because traditional IT operations don’t get involved until AFTER deployment into production – when real users begin hitting the application. How can you expect IT operations to shift left and embrace a culture of DevOps if there is a giant, unautomated chasm in your software delivery pipeline? Asking them to shift left in this context is paramount to asking them to jump of a cliff. If you are doing CI alone, you are likely sole inhabitants of ‘Developer Island’. It might be sunny there, but you are decidedly alone and separate from the rest of the business.

    I know what you’re thinking. This all makes great sense, so why isn’t the CD pipeline automation the norm? The answer is simple… this stuff can be hard and transformation doesn’t happen overnight. It usually begins on the left with CI and as the DevOps initiative matures, CD is the next logical step. It’s certainly not serial out of necessity, but this is the adoption pattern we often see.

    In fact, I have news. Not only does your DevOps transformation not happen overnight, it’s never over. This is all about continuous improvement, which means nothing sits still. There isn’t a DevOps train that terminates at the end of the line. The minute you’ve mastered these best practices, new ones will emerge because every day we as a community get better at delivering software.

    Which brings me to the topic of shift left and continuous everything! When you have both CI and CD pipeline automation in place, you are in a fantastic position from a tools perspective to shift left. This is a perspective shift from problem detection to prevention which means testing earlier, and earlier – effectively shortening test cycle times while preserving code quality. The result? Better software, delivered more quickly that shortens the feedback loop between end users and developers.

    But shifting left isn’t just about tools. It’s also about people and practices – the proverbial DevOps trinity. It means everybody has a stake in the reliable, repeatable delivery of high value software. It means that the documentation team joins the engineering team when stories are being picked for a release. It means that product marketing comes to that same meeting with research on the market opportunity for such a feature. It means that product managers sit on analyst inquiry calls with the analyst relations team. It means that passionate customers beta test features and give meaningful feedback that can be immediately acted upon. It means that before a feature is even released, sales is trained, primed and ready to do pipeline generation. It means DevOps is at the very heart of the business and every function from marketing, to sales to support and services is totally informed and invested from ideation onward. No more chucking features over the wall. No more islands. No more excuses. That’s continuous everything.

    Effective and comprehensive measurement and monitoring

    So you’ve got a CI/CD strategy. You’re shifting left. Now what? A critical – and often overlooked step in DevOps transformation is measurement. It’s time to take credit for how increasingly amazing you are doing! (or understand where you are falling short, DevOps is about honestly accepting and addressing failure or in efficiencies…together). You need visibility in order to know which lever to pull next in your path to continuous improvement. You’re delivering code faster than ever! But how’s the quality? Is it failing tests? Is it unstable in production? How much rework is required? You won’t know if you don’t track it. Implementing and measuring the success of the best practices in DevOps is crucial if you wish to make your automation cycle faster over time. If, like many, you jumped headlong into your DevOps journey without putting monitoring in place – it’s not too late. Consider keeping track of the deployment frequency, change lead time, change success/failure rate, mean time to recovery (MTTR), and the rate of security tests passes in your organization to stay on top of your DevOps transformation.

    8 CI/CD Best Practices to get you started in DevOps

    1. Take a ‘security first approach’

    It’s not possible to overemphasize the need for security in a world where breaches and vulnerabilities continue to cause massive reputation and financial losses to businesses of all sizes and capabilities. Since the CI/CD system offers access to your codebase and credentials to deploy in various environments, it is often the prime target. Recall the infamous Uber breach where hackers gained access to AWS credentials that were embedded in the GitHub software repository – stealing the personal information of 57 million users and 600,000 drivers. Uber then paid to cover it up, but that’s a different story. It’s certainly not uncommon for credentials to be stored in private repositories for automation purposes. Therefore, you should consider isolating your CI/CD systems, placing them in secure internal networks. VPNs, strong two-factor authentication and identity and access management systems will help you enforce ‘the principle of least privilege’ and restrict exposure to threats. For example, containerize your agents and place them on secure networks. In addition, you should also ensure that security is baked into the development process from start to finish. This is commonly known as DevSecOps.

    2. Assess your organization’s readiness to utilize a  microservices architecture

    For effective implementation of DevOps, a microservices architecture is the best way forward. However, re-architecting your existing applications can be a daunting task, and you may consider an incremental approach where you maintain your mission-critical systems and weave the new architecture around it. This will help you gradually replace the old system with the new architecture.

    3. Implement tracking and version control tools

    Tools like Jira and Bugzilla can help you achieve better visibility into the progress of your software and collaborate easily with distributed teams. You will also need a version control system like Git, which creates a ‘single source of truth’ for your team, allows tracking of changes in the code-base, and is a life-saver whenever a rollback is required. By enabling the teams to collaborate and integrate changes into the shared repository, GitOps can significantly improve your MTTR.

    4. Commit daily, reduce branching

    The goal of reducing (or even gasp… eliminating) branching is to spend more time on development and less time on version control. However, to make the most of GitOps, developers are expected to commit directly to the main branch or merge changes from their local branches in at least once a day. This will force developers to deal with smaller, bite-size bits of integration pain instead of the massive integration pain (and associated rework) that happens when attempting to merge many branches into the trunk just before release.

    5. Build only once

    Eliminate any practices where source code is built multiple times. Even if the software has to be built, packaged, or bundled, you should execute that step only once and promote your binaries. Most successful CI implementations include the build process as the first step in the CI/CD cycle to package the software in a clean environment. This eliminates oversights and reduces the chance for errors to be introduced and/or missed anytime later. Further, the resulting artifact should be versioned and uploaded to Git each time so that whenever it is pulled the build does not change.

    6. Decide which processes and tests to automate first

    While an incremental approach to automation sounds good, organizations transitioning from manual to automated processes often find it difficult to decide which processes to automate first. For example, it is beneficial to automate the process for compiling the code first. As developers need to commit code on a daily basis, it makes sense to do automated smoke tests. Unit tests are usually automated first to reduce the workload on developers.

    Consequently, you can automate functional testing, followed by UI testing. Functional tests do not usually require frequent updates in the automation script, unlike UI tests which have more frequent  changes. The main idea is to think about all possible dependencies and evaluate their impact to prioritize automation sensibly.

    7. Release often

    Frequent releases are only possible if the software is in a release-ready state and you have tested it in a production-like environment. That’s why the best practice is to add a deployment stage which closely resembles the production environment before the release. Some release best practices include:

    • Canary deployment. Releasing to a subset of users, testing with that base and rolling it out to the wider population if successful (or rolling it back for iteration if it’s not).

    • Blue green deployment. You begin with two identical production environments. One is live in production. The other is idle. When a new release is rolled out the changes are pushed to the idle environment. Then they switch – the environment containing the new release becomes the live environment. If something goes wrong, you can immediately roll back to the other environment (the one that does not contain the new release). If all is well – the environments are brought to parity once more.

    • A/B Testing. A/B testing is similar in flavor to – but not to be confused with- blue green deployments. A/B testing is a way of testing features within the application for things like usability. The better performing variant of the feature wins. This is not a release methodology.

    8. Use on-demand testing environments

    You should consider running tests in containers as this approach allows the quality assurance team to reduce the number of environment variables and changes present between the development and production environments. The primary advantage of using such ephemeral testing environments is that they add agility to your CI/CD cycle. The QA team does not have to pull a build from a CI server and install it in a separate testing environment; instead, it can run tests against a container image. It is much easier to spin up containers (they have no separate installation or configuration requirement) and also destroy them when not needed.

    Where to begin?

    The primary goal of DevOps or CI/CD best practices is to automate the process of building, testing and releasing software. This means you will need access to DevOps tools that help you simplify automation as well as get better visibility into the progress of your software. Further, there should be a mechanism to track DevOps performance metrics throughout the software delivery lifecycle and raise alerts for quick recovery when something goes wrong in release or deployment.

    Deciding which DevOps tools to implement and where to invest first can cause “analysis paralysis” – even in organizations that have been working through their DevOps transformation for some time. You can avoid getting stuck in a similar position and jumpstart your DevOps transformation with the CloudBees Starter Kit. Learn more about this starter kit here.

    Additional resources