Category: Continuous Delivery

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

  • OverOps Integrates AI Code Analyzer With CI/CD Platforms

    OverOps Integrates AI Code Analyzer With CI/CD Platforms

    At the DevOps World | Jenkins World 2019 conference, OverOps announced it has integrated its namesake tools for analyzing Java and Microsoft .NET code at runtime with a variety of continuous integration/continuous deployment (CI/CD) platforms, including Jenkins, JetBrains TeamCity, Atlassian Bamboo and Pivotal Concourse.

    Eric Mizell, vice president of solution engineering for OverOps, noted that the more errors that are discovered by DevOps teams early in the development cycle, the less technical debt organizations must address after an application is deployed in a production environment. By pushing testing to further to the left of the application development process, the less troubleshooting will be required later on, he said.

    OverOps employs predictive analytics and machine learning algorithms to identify new, increasing, resurfaced and critical errors in a release. It then generates a code quality report that ranks all severe issues likely to impact end users and application functions. By integrating OverOps within the CI/CD pipeline, DevOps teams can use those reports to determine whether code is safe to promote or automatically block unstable releases from moving forward.

    In addition, because the machine learning algorithms surface the true root cause of an issue, DevOps teams can more efficiently remediate issues by routing code back to the development team responsible for all the issues that are being created downstream.

    Making testing an integral part of the CI/CD process not only tightens the relationship between developers and testers, but also in many cases enables developers to test their own code before submitting it for review.

    Mizell said the need to shift testing to the left has become more critical as customer tolerance for application errors is low, especially in use cases involving mobile applications—consumers are especially unlikely to give a mobile application a second chance after they’ve encountered an issue.

    In an ideal world, of course, testing tools that make use of machine learning algorithms would be employed to coach developers in a way that enables them to develop reliable code more consistently and faster. However, some organizations will use tools that leverage machine learning algorithms to identify developers who are not meeting expectations. That weeding out process is likely to begin much earlier in the application development life cycle as more advanced testing tools are embedded within CI/CD environments. Those tools won’t eliminate the need for developers and testers, but they do promise to increase dramatically the rate at which quality applications can be built and deployed at an industrial scale. Technical debt may never be completely eliminated, but at the very least the rate at which that technical debt is being accumulated should substantially decline.

    It may be a while longer before machine learning algorithms and other forms of artificial intelligence (AI) are employed pervasively across DevOps processes. In most cases, those algorithms will help developers write better code faster. However, it’s also apparent there will be other algorithms at work that one way or another ensure developers will have fewer opportunities to make mistakes in the first place.

    — 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

  • Doing DevOps in an Interconnected World

    Doing DevOps in an Interconnected World

    Doing DevOps would be simple if you had total control over the tools, code and infrastructure that your company used. But the fact is, you don’t. Instead, we live in a world where most CI/CD chains connect in some way to third-party resources or processes.

    In other words, doing DevOps effectively means integrating with entities that are external to your organization. Here’s a look at what this entails in practice and why it’s so important.

    The Interconnected World of DevOps

    Conversations about DevOps often assume that all DevOps processes happen internally. In reality, many software delivery pipelines depend on third-party resources and services. Consider the following examples of ways companies could make their software delivery chains dependent in part upon third-party agendas:

    • They integrate open source code into their codebases and therefore depend on an open source community to write some of their code.
    • They maintain relationships with partners and need to be sure their release schedules and toolchains are compatible with their partners’ needs.
    • They need to make sure the applications they deliver work on different operating systems, browsers and hardware devices that are controlled by third parties.
    • They are subject to regulatory rules handed down by third parties and must ensure their delivery chains meet those regulatory requirements.
    • Their applications depend on APIs that are designed and updated by third parties.

    In these ways and more, the CI/CD pipelines organizations build to do DevOps need to be able to integrate with, and adapt to, decisions made by third parties. If they don’t, the organizations risk problems such as broken code, the loss of partners and regulatory compliance issues.

    Succeeding at Interconnected DevOps

    This is why it’s critical to design CI/CD pipelines and other DevOps processes in ways that make them mesh with third-party resources and services. In practice, this means:

    • Adopting tools that are flexible and have broad coverage. You don’t want to tell a partner you can no longer work with their code because your CI server doesn’t support their new programming language.
    • Use branching in the CI/CD process. Multiple branches give you more flexibility to support different target environments. They also help you react to sudden changes made by third parties without having to overhaul your entire CI/CD process.
    • Make sure your collaboration and communication channels integrate with those of third parties on whom you depend. If you use open source code in your application, for example, add the open source project’s security announcements to your Slack channel so you’ll be notified right away when a vulnerability arises.
    • Choose your integrations wisely. Just because you can integrate a third-party API into your application, for example, doesn’t mean you should. Too many dependencies put the efficiency of your CI/CD pipeline at risk.

    No matter the details of your CI/CD chain, the most important thing is simply to recognize that we live in a very interconnected world and most organizations don’t have total control over their software delivery processes. That’s just a fact of modern DevOps. But with the right planning and strategies, you can ensure that third-party dependencies add value to your software delivery pipeline rather than creating unnecessary risk and overhead.

    — Chris Tozzi

  • 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

  • GitLab Expands Scope of DevOps Ambitions

    GitLab Expands Scope of DevOps Ambitions

    GitLab, with the release of its 12.0 update, is extending the reach of its namesake continuous integration/continuous delivery (CI/CD) platform to include both cybersecurity professionals and traditional IT operations staff.

    John Jeremiah, senior product marketing manager at GitLab, said the goal is to provide organizations with a single CI/CD platform that unifies the management of everything from source code to best DevSecOps processes.

    To address that latter requirement, GitLab 12.0 adds a dashboard designed specifically for security personnel along with the ability for cybersecurity teams to approve merge requests and automatically apply patches for vulnerabilities detected. Those capabilities complement existing support for scanning and secrets detection.

    New capabilities embedded in the platform for IT Operations professionals include an operations dashboard and an embedded incident management capability that makes it easier to create a coordinated response to a specific event.

    GitLab 12.0 also adds support for feature flags to better manage the application delivery process, along with a platform-as-a-service (PaaS) environment to provision and maintain the infrastructure needed for developing and launching an application.

    Jeremiah said the new and existing capabilities in GitLab will make it possible for organizations to unify their DevOps tool chains in a way that also enables IT operations teams and cybersecurity professionals to be included in the process.
    At the same time, GitLab is making DevOps more accessible by eliminating many of the silos between various tools that have emerged over the years, including, for example, built-in support for feature flagging versus requiring organizations to acquire and maintain a separate tool, he noted.

    Because those capabilities are embedded in the platform, organizations will be able to make the cultural shift required to adopt DevOps more easily, he added. IT teams don’t always know what other tools they will need as their DevOps skills mature. With all the tools embedded in GitLab readily available, it becomes easier for organizations to expand their DevOps processes as the organization starts to implement more sophisticated processes, Jeremiah said.

    That approach is starting to resonate with the 100,000-plus developers actively using the GitLab platform and more than 2,000 contributors actively contributing code to the underlying open source platform, he added. GitLab in March saw its millionth merge request.

    It’s too early to tell how broadly any CI/CD platform might be able to consolidate the DevOps toolchain. Developers are notorious for adopting new tools as they see fit. Internal IT teams, of course, are not always excited to be asked to support yet another tool. The right level of balance between ultimate flexibility and the need for a standard set of processes that can be implemented across multiple application development teams must be determined by each organization.

    In the meantime, DevOps processes are starting to expand beyond traditional development team to now include IT operations staff and cybersecurity personnel. The challenge now that they’ve been invited to the proverbial DevOps party is making them feel welcome and appreciated.

    — Mike Vizard

  • CloudBees’ Acquisition of Rollout: The CEOs’ View

    CloudBees’ Acquisition of Rollout: The CEOs’ View

    As Mike Vizard reported yesterday, CloudBees, as part of its mission to build “the world’s first end-to-end automated software delivery system,” announced another acquisition: Rollout, a developer of a feature flag application that allows for simplified testing of new modules within an application.

    Not to repeat the gist of Vizard’s article; you can read it for yourself. But this continues what has become something of an acquisition tear by CloudBees. The company has acquired CodeShip and Electric Cloud, among others, while becoming one of the founding members of the new Continuous Delivery Foundation (CDF), under the Linux Foundation and a sister foundation to the Cloud Native Computing Foundation (CNCF) and the Cloud Foundry Foundation. The CDF is now managing the Jenkins project, as well as Jenkins X, Spinnaker and Tekton.

    CloudBees’ Mission

    Make no mistake: These acquisitions, along with the CDF formation, represent a major change for CloudBees. The team there is clearly trying to separate from the pack of “end-to-end” DevOps contenders. CloudBees CEO Sacha Labourey is pushing hard to raise CloudBees above the noise and the rest of the market. The company announced a $62 million round of financing about a year ago.

    You don’t have to be Warren Buffet to see that CloudBees sees an opportunity here. The company is driving toward achieving scale in product and revenue on the path to some sort of liquidity event (perhaps an IPO?) or market leading opportunity.

    For now, though, back to the Rollout acquisition. I had the chance to sit down with Labourey and the CEO and founder of Rollout, Erez Rusovsky. We discussed what Rollout does, its history and how it will fit into the CloudBees product portfolio.

    It is always great to interview a founder about his company being acquired. What a tremendous feeling of accomplishment to found and build a company, and have another entity value it so much that you are willing to sell it to them. This goes so far beyond validation.

    Congrats to Erez and the whole Rollout team and, of course, congratulations to Sacha, KK and the rest of the CloudBees team. This seems like a perfect fit.

    In the meantime, here is my conversation with Sacha and Erez on the acquisition and more. Enjoy!

     

    — Alan Shimel

  • CloudBees Acquires Rollout for Feature Flagging

    CloudBees Acquires Rollout for Feature Flagging

    CloudBees today announced it would extend the reach of the Jenkins continuous integration/continuous development (CI/CD) platform by acquiring Rollout, a provider of feature flag tool that gets employed to simplify testing of new modules within an application.

    Company CEO Sacha Labourey said the acquisition of Rollout would result in a feature flag capability that is more seamlessly integrated with the gates that make up a CI/CD pipeline process. The goal is to make it easier for DevOps teams to apply A/B testing of new application features against a subset of users before deciding to update an entire application environment, he said.

    Feature flagging, also known as feature toggling, enables DevOps teams to hide features from certain users at runtime. In effect, this creates multiple branches from the same source code that DevOps teams need to manage. Rather than having to employ a separate tool based on an entirely different user interface, CloudBees is moving to make feature flagging a core capability of its extended toolchain.

    In theory, feature flagging should be more widely employed than it is today. Many organizations, however, have found it challenging to incorporate separate feature flagging tools within their DevOps processes. CloudBees is now using some of the money it has raised of late to address that issue.

    Feature flagging today is largely confined to testing. However, there may come a day when more organizations will employ feature flagging to make different classes of user experience available to different end users. That approach, in theory, would make it possible to charge different fees for disparate application experiences using the same core application.

    In the meantime, the goal is to garner more feedback concerning new capabilities that might be added to an application before the features are made generally available. Developers often spend months developing new features only to discover end users are not employing those capabilities because of some trivial glitch that could have been discovered easily using A/B testing.

    There currently is no shortage of options when it comes to tools for implementing feature flagging. Labourey said CloudBees elected to acquire Rollout because the team behind it was deemed to have the best cultural fit with CloudBees. It’s too early to say whether other providers of feature flagging tools will be rolled up into other CI/CD platforms—providers of those platforms can either develop their own feature flagging toolsets or move to absorb a third-party provider either by acquiring them or forming a technology alliance. The depth of the toolchain being provided these days often has as much to do with what CI/CD platform ultimately gets adopted as the core integration and delivery capabilities.

    Regardless of the path chosen, it’s apparent that thanks to feature flagging, continuous testing processes will become more sophisticated. That may require some adjustments to existing best DevOps practices, but the days when development teams blindly experiment on end users in the hopes they are building the next killer feature mercifully are coming to an end.

    — Mike Vizard

  • GitLab Updates Advance Its CI/CD Platform

    GitLab Updates Advance Its CI/CD Platform

    GitLab has expanded the capabilities of its continuous integration/continuous development (CI/CD) platform to include tighter integration with collaboration platforms from Slack and Mattermost along with the ability to support Docker containers running on Windows.

    Version 11.11 of GitLab adds a caching dependency proxy for Docker images to the Premium edition of GitLab along with the ability to provision an instance-level Kubernetes cluster using instances of GitLab that are managed by an internal DevOps team. Those capabilities are arriving on the heels of GitLab last month announcing its initial support for Kubernetes as a platform on which its CI/CD environment now can be deployed.

    The latest edition of GitLab also adds support for multiple assignees for a merge request capability, which allows multiple members of a DevOps team to manage merge requests within a DevOps pipeline.

    Finally, GitLab 11.11 also provides guest access to releases, extends the add-on CI runner minutes to the GitLab Free edition, supports the OpenID Connect authentication protocol, includes serialized commit graphs and simplifies reviews by auto-resolving a discussion whenever a suggestion is applied.

    Priyanka Sharma, technical evangelist for GitLab, said GitLab is starting to see increased interest in using Docker containers to build applications on Windows. A Windows Container Executor for GitLab Runners capability makes it easier to orchestrate pipelines that include Docker containers destined to be deployed on Windows. Previously, DevOps teams needed to rely on a shell executor to orchestrate Docker commands. This update makes it possible to employ Docker containers on Windows in the same way they are deployed on Linux platforms. GitLab also has improved support for PowerShell, in addition to making available helper images for various versions of Windows containers.

    Sharma said GitLab is starting to see IT organizations that have embraced Windows starting to catch up in terms of enthusiasm for Docker containers. Also, DevOps teams that have embraced both Linux and Windows platforms are looking to apply best DevOps practices to both platforms.

    Microsoft has signaled its intention to continue investing in making Docker containers a core element of its overall strategy. As the work progresses in collaboration with Docker Inc., the need for a CI/CD platform that can support Windows environments will become more acute.

    In the meantime, GitLab continues to focus on making it easier to implement best DevOps practices at scale, Sharma said. As enterprise IT organizations continue to embrace DevOps, many of them soon discover the need for a CI/CD platform designed from the ground up to support pipelines that are being accessed by many concurrent users.

    The decision many of those enterprise IT organizations will have to make is how much they will want to rely on an open source versus closed source platform. The enterprise edition of GitLab is a closed source platform, but the company does make available an open source community edition. While the open source Jenkins platform currently dominates among CI/CD platforms, enterprise IT organizations that have adopted DevOps have shown a willingness to embrace proprietary DevOps platforms that address challenges ranging from the scale of deployments to security and compliance.

    It’s too early to say how the next major CI/CD battle involving the shift to microservices will play out. However, if history is any guide, there should be plenty of room for both open source and proprietary CI/CD platforms.

    — Mike Vizard