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.

  • Wind River Launches CD Platform for Embedded Systems

    Wind River Launches CD Platform for Embedded Systems

    Wind River is fostering the adoption of DevOps processes for embedded systems by making available a continuous delivery (CD) platform that its customers can download.

    Glenn Seiler, vice president for open source strategy for Wind River, said the CD platform is based on an open source instance of the Jenkins continuous integration/continuous delivery (CI/CD) platform. The company envisions organizations downloading the platform as source code that Wind River will update regularly for use on top of the Wind River Linux platform, he said.

    Wind River is taking advantage of containers, Kubernetes, the Puppet IT automation framework and a repository to ease deployment of its CD platform, added Seiler. The company is committed to providing updates to that platform, which Wind River uses internally, at least every three weeks, said Seiler.

    Wind River expects most organizations will already have some form of a CI process in place. The CD platform provided by Wind River will focus on accelerating the delivery of applications built using whatever CI process organizations have in place today, said Seiler.

    In the embedded systems space, Seiler said the adoption of best DevOps practices is still in its very early days. However, with the rise of edge computing and the internet of things (IoT), organizations will need to find a way to securely deploy and update highly distributed application environments. To achieve that goal, many organizations will apply the same DevOps principles enterprise companies have been applying to their embedded systems, he said.

    To ensure the integrity of the software supply chain on which the Wind River CD platform is delivered, Wind River has also been certified under the ISO 9001:2015 specification for management processes, as well as the OpenChain specification for open source compliance.

    Wind River also has the Wind River Workbench for Linux LTS, based on the Eclipse integrated development environment (IDE), along with various system analysis tools including a trace visualization tool from Percepio AB to identify the root cause of anomalies.

    While it’s taken more than 10 years to drive the adoption of best DevOps practices in the enterprise, adoption in embedded systems environments should be faster now that the journey has begun. Organizations of all sizes are pushing more application workloads to the edge at faster rates. Traditional approaches to building and deploying applications on standalone embedded systems will not be able to keep pace. Organizations that build applications for embedded systems will be challenged by first acquiring the right tools and then adapting their internal culture to the complexities that arise when they need to build and deploy applications faster.

    Wind River is making the case for a curated open source CD platform that should enable organizations to spend less time on managing the underlying DevOps platform in favor of focusing more time and energy on changing their internal culture.

    — Mike Vizard

  • F5 Networks Launches Next-Gen ADC Based on NGINX

    F5 Networks Launches Next-Gen ADC Based on NGINX

    F5 Networks this week launched version 3.0 of its NGINX application delivery controller (ADC) that adds application programming interface (API) management tools, analytics and monitoring tools, a service mesh, a certificate manager, a developer portal and integrations with multiple continuous integration/continuous deployment (CI/CD) platforms.

    Ken Bocchino, director of product management for NGINX at F5 Networks, said as the first major update to the NGINX Controller since F5 Networks acquired NGINX last year, the 3.0 release represents a concerted effort to reduce the total cost of DevOps by bundling many capabilities that previously would have needed to be acquired separately.

    In addition, NGINX Controller 3.0 reduces the complexity associated with building DevOps workflows because all the components that make up NGINX Controller have been pre-integrated, said Bocchino.

    Based on the open source NGINX proxy server, NGINX Controller is the mechanism through which commercial capabilities are provided and supported as part of the NGINX Plus subscription service offered to enterprise IT customers. Previous iterations of ADCs were much more infrastructure-centric than application-centric, noted Bocchino.

    While F5 Networks naturally would prefer IT organizations to consume all those services, Bocchino said the ADC has been designed in a modular fashion to enable organizations to consume services exposed as REST APIs as they see fit. A future version of the NGNIX proxy server will be able to support multiple types of service meshes, including the lighter-weight offering created by the NGINX team that will become available later this year as part of NGINX Controller 3.0, he said.

    Bocchino noted F5 Networks envisions the NGINX Controller playing a major role in driving further convergence across network operations, security and DevOps teams. NGINX Controller 3.0 facilitates that goal by providing a self-service portal along with role-based access controls and modular workflows that eliminate the need for tickets to be issued to achieve every IT task.

    It’s not clear at what rate that convergence is occurring. However, F5 Networks last year published a survey of DevOps and NetOps teams that suggests there is still a wide gap between NetOps and DevOps teams. The survey found only a little more than a third (38%) of DevOps teams cited the “integration of toolsets across vendors/devices” as a challenge to network automation. In contrast, almost half of NetOps respondents (47%) noted a lack of integration as a problem, second only to a lack of automation expertise (49%).

    F5 Networks by acquiring NGINX is betting than most organizations that have already embraced NGINX proxy server software would rather extend those existing capabilities versus replacing their ADC with a new stack of software based on, for example, the rival open source Envoy proxy server being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    How the proxy server war and associated ASC platform wars will play out is still anybody’s guess. What is clear is that DevOps teams will need to access a wide range of programmable networking and security services easily to take DevOps to the next level.

    — Mike Vizard

  • GitLab Updates Core CI/CD Platform

    GitLab Updates Core CI/CD Platform

    GitLab this week delivered an update to its namesake continuous integration/continuous delivery platform that promises to make pipelines more efficient and easier to manage, in addition to making it easier to set up pipelines in Windows environments.

    Version 12.7 of the core GitLab platform adds support for Parent-Child Pipelines and Pipeline Resource Groups. Parent-Child Pipelines make it possible to run separate child pipelines concurrently, while Pipeline Resource Groups enable DevOps teams to limit pipeline concurrency to better manage jobs and resources.

    A Code Review Analytics module is designed to make it easier to find Merge Requests in review that require some level of intervention, while enhanced Merge Request widgets show when changes have made it to a specific environment.

    Other new capabilities include being able to automatically stage all changes with the GitLab integrated development environment (IDE) and the ability to share group access with another group.

    Finally, GitLab has added a beta release of Windows Shared Runner, which brings Windows environments to the GitLab platform via a managed service. Darren Eastman, senior product manager for Runner at GitLab, said instead of having to separately download agent software through which jobs on a GitLab pipeline are executed, Windows environments are becoming full-fledged citizens of the GitLab platform.

    Eastman said IT organizations running Windows compared to their Linux brethren are still playing a little catch-up in terms of DevOps maturity. However, with the arrival of microservices based on Docker containers on Windows, the need to embrace best DevOps practices to manage application development and deployment is becoming more apparent, he said.

    Of course, Microsoft is pushing its own rival CI/CD platform in the form of Azure DevOps, formerly known as Visual Team Studios. GitLab is betting that most organizations will prefer to consume a fully managed CI/CD service that spans both Windows and Linux platforms, especially as hybrid cloud computing gains traction in the months and years ahead.

    Regardless of the CI/CD platform employed, the overall size of the DevOps community should expand considerably in 2020 as more organizations that rely on Windows to build and deploy applications embrace DevOps’ core principles. Naturally, competition between Microsoft and providers of rival CI/CD platforms will be fierce. Microsoft in many ways is a behemoth that was constructed mainly by a loyal base of developers that the company can be expected to guard jealously. However, as Microsoft has embraced Linux alongside Windows in the cloud, the number of Windows developers who have been exposed to alternative platforms has increased.

    In the meantime, organizations that have teams that build and deploy applications on both Windows and Linux will have some cultural challenges to overcome should they decide to standardize on a common set of DevOps processes. Rather than managing each platform in isolation, there’s a clear opportunity to reduce costs and increase application development efficiency. The issue now is determining which DevOps platform might best enable them to begin a journey that is likely to take a few years to fully complete.

    — Mike Vizard

  • CircleCI Extends Orbs Ecosystem for CI/CD

    CircleCI Extends Orbs Ecosystem for CI/CD

    CircleCI announced today it has added integrations in collaboration with 20 partners to the family of connectors, known as Orbs, that it makes available for its continuous integration/continuous delivery (CI/CD) platform.

    Thomas Trahan, vice president of business development for CircleCI, said integrations are now available with Heroku, AWS, Cloud Foundry, Google Cloud, Red Hat, Helm, Kublr, Alcide, Azure, DeployHub, Fairwinds, VMware, Kubernetes, Rafay Systems, Pulumi, Convox, Spinnaker, realMethods, Quali, Pantheon, LaunchDarkly and Salesforce.

    Since launching Orbs a year ago, CircleCI claims there are now more than 13,000 organizations using Orbs across nearly 40,000 repositories and 9 million CI/CD pipelines. There are also more than 1,200 Orbs provided by more than 116 partners listed in the CircleCI registry. In the future, Trahan said the company plans to begin surfacing recommendations concerning which Orbs to employ based on the nature of the workflow being constructed.

    Trahan said Orbs are gaining traction because they reduce the amount of custom code that needs to be written to set up workflows across a CI/CD pipeline. Without the existence of Orbs, DevOps teams are forced to rely on application programming interfaces (APIs) that are more liable to break, he said.

    Competition between CI/CD platform providers is expected to become fiercer as adoption of CI/CD platforms continues to accelerate. A report published by Data Bridge Market Research this week forecasts demand for continuous integration (CI) tools alone will grow to $18.9 billion by 2025, representing a 19% compound annual growth rate. While the current CI/CD market is dominated by open source platforms managed by internal DevOps teams, CircleCI is betting interest in accessing a managed CI/CD service delivered via the cloud will rise as organizations opt to devote more resources to building applications versus managing the platforms they are built on.

    A recent CircleCI study of more than 30 million workflows spanning 1.6 million jobs runs per day on its platform found 80% of all workflows finish in less than 10 minutes. Those jobs spanned 150,000 projects launched by more than 40,000 organizations.

    The report noted 50% of those organizations start six workflows per day across their projects and that 50% of CircleCI projects never had a failure during pipeline changes made over the 90-day period when the study was conducted. When a failure did occur, 50% recovered in less than an hour, with 25% of organizations recovering in 15 minutes or less, according to the report.
    As organizations embrace best DevOps practices more broadly, CircleCI is betting these kinds of metrics will become more important as a platform differentiator.

    Naturally, it’s too early to say how the CI/CD platform wars will play out in the months and years ahead. But the amount of code organizations will need to deliver at increasingly faster rates is only increasing. The challenge organizations are facing now is finding a way to deliver all that code at an unprecedented level of scale.

    — Mike Vizard

  • Datadog Adds Support for Microsoft Azure DevOps

    Datadog Adds Support for Microsoft Azure DevOps

    Datadog has added support for Microsoft Azure DevOps to its namesake monitoring and analytics platform.

    Ilan Rabinovitch, vice president of product and community for Datadog, said Microsoft Azure DevOps, formally known as Visual Studio Team Services, is gaining traction as a continuous integration/continuous delivery (CI/CD) platform that can be deployed on-premises or in the cloud.

    Via this integration DevOps teams that have adopted Microsoft Azure DevOps can now pull in events to create metrics from their continuous integration pipelines, and then correlate that information in real-time against Datadog is pulling from their entire stack in Datadog. DevOps teams can also configure to monitor gates in their Azure DevOps deployment pipelines, enabling them to detect and abandon bad releases automatically, said Rabinovitch.

    Finally, DevOps teams can also employ Datadog to measure the efficiency of their processes by tracking, for example, how often builds are completing or failing or the frequency of code commits, added Rabinovitch.

    Datadog Microsoft

    Microsoft has been pouring significant resources into building out Microsoft Azure DevOps over the course of the last year. At the recent Microsoft Ignite 2019 conference, the company released Azure DevOps Server update 1.1 release candidate to address some bug issues before organizations deployed the platform in production environments. Microsoft also has added previews of auditing tools, extended reporting capabilities, enhanced the user interface for the repositories page to be more mobile device friendly and added more billing options.

    Microsoft Azure DevOps in time will play a much larger role in the company’s bifurcated approach to hybrid cloud computing. On the one hand, the company is driving an increasingly larger portfolio of Azure public cloud services. In on-premises IT environments there is a massive base of Windows servers coupled with a nascent Azure Stack platform that provides organizations with the option to deploy the same IT environment Microsoft employs on its public cloud. The long-term goal is to make it easier for organizations to build and deploy applications across hybrid cloud computing environments using the same DevOps pipeline.

    Of course, Microsoft Azure DevOps is not the only CI/CD platform that might be employed to achieve that goal. As rival CI/CD platforms continue to extend their reach into Azure and Windows environments, Microsoft will find itself competing with a small army of rival DevOps platforms that span not only Azure, Windows and Linux platforms but also rival cloud platforms such as Amazon Web Services (AWS) and Google Cloud Platform (GCP).

    In the meantime, IT organizations should expect to see a host of third-party tools becoming available for Microsoft Azure DevOps as the CI/CD platform gains traction. In some cases, organizations will standardize on Microsoft Azure DevOps. In other cases, Microsoft Azure DevOps will become one of several CI/CD platforms that different teams within an organization are employing. Regardless of the CI/CD platform adopted, however, organizations that do wind up employing multiple CI/CD platforms are likely to want to consolidate as many as the monitoring tools they rely on as possible.

    — Mike Vizard

  • DevOps Chats: Automic + CA + Broadcom, a Release Automation Journey

    DevOps Chats: Automic + CA + Broadcom, a Release Automation Journey

    The life of an acquired company can be an exciting one full of unexpected twists and turns, and that’s been true of Automic software. Scott Willson, a repeat podcast guest and longstanding member of the DevOps community, joins us again on DevOps Chats. He describes his acquisition journey as being akin to a “barracuda, eaten by a great white shark, eaten by a whale.” Scott is product marketing director, Release Automation at CA Technologies, a Broadcom company (the new proper name for Automic + CA + Broadcom).

    Scott shares what it’s like being a software DevOps company inside Broadcom, whose strong roots come from the chip manufacturing business. While software has its many differences from chips, of course, Scott shares how many of the DevOps principles and heritage from lean manufacturing have made the transition easier. There are valuable lessons here for all of us.

    Amid all the change, Automic shifted its products to the freemium model. Automic Continuous Delivery Director is now free to use for up to 10 active releases. We talk about the upcoming releases, which includes machine learning. Join us as we bob and weave through the acquisition story into the world of continuous automated delivery.

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chats podcast. Today, I’m joined by Scott Willson, he’s product marketing manager, Release Automation at CA Technologies at Broadcom—that’s a mouthful. I think we’re gonna explore a little bit of that.

    So, our topic today is really catching up with what’s been happening with the Automic product and CA’s, this part of the acquisition back into Broadcom and just kinda catch up with Scott. So, he’s been on the podcast before. Scott, welcome to DevOps Chats.

    Scott Willson: Thank you, Mitch. Glad to be here.

    Ashley: Appreciate you being here. Would you start just by introducing yourself for any of our audience that doesn’t know you, a little bit about what you do, and tell us a little bit about CA Technologies at Broadcom.

    Willson: Yes, yes, so my name is Scott Willson—two Ls in Willson. I think many listeners may know me. I have been, in the past, an author with some of Gene Kim’s DevOps Forum papers, and I’ve been at the DevOps Enterprise Summit several times. I’ve been fairly active on blogs and all that stuff.

    And where my kinda claim to fame was, I came from a company called Automic. That’s spelled Auto-mic for the phonetic spelling of it. My background is, just to throw this in here, too, my journey, as I always tell people, is I started from a development standpoint writing the code, migrated my career kinda doing the DevOps thing before anyone called it DevOps, like many others.

    Ashley: Mm-hmm.

    Willson: And yadda yadda yadda, here I am now with a software company speaking all things DevOps and trying to help people get better at releasing their software.

    Ashley: You’ve certainly been a part of the community for some time now, so we appreciate all your contributions. Well, you’ve been through quite a journey. I know being acquired by CA and then CA being acquired by Broadcom—why don’t you kinda catch us up? Maybe tell us a little bit about that journey. I think you described it as an 18 month history going through that.

    Willson: [Laughter]

    Ashley: You know, we don’t have too long on the podcast, [Laughter] but if you can kinda give us a little bit of that path that you’ve been on.

    Willson: Yeah, yeah. You know, I kinda looked at it like a, it was almost like a barracuda eating a great white who was eaten by a whale, right?

    Ashley: [Laughter]

    Willson: It was a really interesting, very quick journey. It was a couple years ago when I was with Automic Software. We were acquired by CA Technologies, and about a year or 18 months after that acquisition or so, Broadcom bought CA Technologies to the—not just our surprise, but of course, to the surprise of the entire market.

    Ashley: Mm-hmm, yeah, it was.

    Willson: There was a lot of press about it.

    Ashley: It was a surprise.

    Willson: And so, yeah, it was a very, very quick and interesting turnaround. We are now known as CA Technologies, a Broadcom company. As far as Automic goes, we are retaining the Automic brand, so you’ll see a lot of our old software and all that will have the Automic brand. And not just Automic, but our current leadership has really felt to really keep and embrace the brands that we’ve had. So, you know, Blaze—CT is still gonna be Blaze, and Rally is gonna be Rally, those type of things.

    Ashley: Mm-hmm.

    Willson: So, the brands are remaining, which I think is useful, because even though CA had remained Rally—I know I, anyways, always refer to it as Rally, because—

    Ashley: I do, too, yep. [Laughter]

    Willson: – right, because that’s what I always knew it as. [Laughter]

    Ashley: Especially knowing them from the beginning, it’s hard not to call them Rally, but yes.

    Willson: Right, exactly. So, Automic is still going to be Automic from a product brand positioning. And then from a company standpoint—yeah, we’re still CA, just a Broadcom company. Within Broadcom, our group is known as the Enterprise Software Division, so we are a distinct division within Broadcom.

    Ashley: Mm-hmm.

    Willson: And then, to add to that, to the little journey, what has been interesting to me is—I remember it was a year ago, the last Forum meeting I was going to or what many of us in the inside called those meetings, the Gene Kim’s Great Slumber Party.

    Ashley: [Laughter]

    Willson: Right? We kinda talked about being lean, and some of the people, I remember having discussions with and running papers, we just really got to talking about what it means to run lean and the lean manufacturing and the whole thing, right, that DevOps is based on and that The DevOps Handbook espouses and all these kinda things.

    And after that, right, three months after that meeting it was announced Broadcom was gonna buy us and then they actually did, and here I am all this time later. And I bring that up because what was interesting to me, Mitch, is that Broadcom embodies this. They run lean.

    Ashley: Mm-hmm.

    Willson: And it’s been an interesting journey to go from the short time at CA, which ran big, to now being with Broadcom, which runs lean. And they run even leaner than what Automic did, which was in ISV, right? You know, Independent Software Venture.

    Ashley: I was curious about that, because I know Broadcom, you know, I had worked with them as a chip supplier with companies like Broadcom ad Qualcomm and, you know, manufacturers of chips in telecommunications think about the world, they’re much more, you know, operational efficient. It’s all about fractions of pennies and the cost of their goods to maintain profitability, but that’s super high volume. So, it’s a different mentality than a software company.

    Willson: It is, and there are some significant differences, I suppose, from the business or sales aspects. But from a production aspect, there really wasn’t a whole lot of difference. When you think about taking a product to market, right? Now, we were doing this with software, they’ve done it with chips, but Broadcom is an engineering excellence company. They really pride themselves on having the best of fill in the blank of engineering, whether it’s engineering processes, engineering whatever. In fact, what has been interesting post acquisition is that our engineering staff for the bulk of our products have actually increased. Broadcom is very keen on ensuring that the products we deliver are best in class.

    Ashley: Mm-hmm.

    Willson: And so, they realized a way to do that in the market is to make sure they’ve got the top minds developing and producing and shipping these products, right?

    Ashley: That has to be refreshing to you—you and the team.

    Willson: Oh, yeah. It was very interesting to see that that was the case. It’s been a unique acquisition as far as that goes, and to see that—no, they wanted to increase the head count of R&D. [Laughter] It’s important for them.

    Ashley: Mm-hmm. What? [Laughter]

    Willson: Exactly. Like—wait, what? They want the products to improve, to get better, and to continue to be viable and market leading. And so, they embody the lean processes to do all of this stuff. And so, it’s been—there’s a little bit of a learning curve, I think, on both sides to adapt to this new way, but here we are. You name the things that are automated—I mean, Broadcom automates just about anything and everything. The very stuff you read about, Gene Kim talks about in his book, saying—and even in Nicole Forsgren’s book, Accelerate, you know, automation is at the key of a lot of these things, and Broadcom embodies that.

    Ashley: It is. It’s a much different kind of company. If you’re not a hardware person or haven’t worked at a chip company, what I said, it’s—fractions of a penny make a difference in cost, and that cost can be in materials, but it also can be in process. And when you multiply that by millions upon millions of chips that they may ship a particular line, that’s a lot of money. So, it makes a huge difference in the profitability of the company—

    Willson: That’s right.

    Ashley: – to be able to reinvest and give you more engineers to be part of your team.

    Willson: That’s right. And so, software is a little different, right? It’s not the pennies like that. Obviously, with software, the margins are different, because you’re not dealing with a physical thing, a commodity, right? But the principles to be efficient like that are absolutely espoused by DevOps. And one of the things that this transformation internally has occurred—because we’re transforming ourselves from a software company, right? I think we’ve made some press releases talking about our BizOps platform, a holistic platform—

    Ashley: Right.

    Willson: – that we’re offering the market. No longer should you be thinking of us like the CA of old where you had a bunch of different siloed tools. Now, they’re all coming together in a holistic way to provide real business value and create a true, interesting platform for everybody.

    Ashley: Mm-hmm.

    Willson: But just this way of doing things lean like that and embracing the agile way of turning things around has been a cool thing to behold.

    Ashley: That has to be really good, because I haven’t talked with somebody that’s had that experience—not that others haven’t, but to have that common lexicon frame of reference of thinking about producing software like a software factory just like a hardware based factory. You have a lot of synergies and commonalities there. Yeah, there’s differences, too, but instead of software being this mystery to hardware guys or vice versa, right, you can talk and work together and understand the efficiencies, improvements, speed, impact, quality—all the things that drives the manufacturing company also drives software.

    Willson: That’s right. And what’s been exciting, too, with this opportunity to change—really, the Broadcom offer has provided us an opportunity to change things and to really force these integrations and synergies between what used to be separate divisions of CA but are now different teams and the interoperability that’s happening between them to deliver this BizOps platform is really exciting. It’s cool to see that now it’s like—look, we have all these things, but what’s the point, unless we’re focusing on business outcomes, right?

    Ashley: Right.

    Willson: We can actually drive a business outcome if there’s harmony and cohesiveness between all these things, and that’s very exciting. In fact, one of the other things along these same lines that was announced is the free tier program—I don’t know if you see the PR a couple weeks ago, Mitch—

    Ashley: I did.

    Willson: – but now, a lot of our products are offered for free.

    Ashley: Yeah.

    Willson: So, for example, a continuous delivery director, or Automic Continuous Delivery Director, if you go to CDDirector.io, you can just use it for free, up to 10 active releases. And Rally has some free tier as well. So, basically, we’re now offering the freemium versions of what we had, and—

    Ashley: Have the products changed substantially to be able to do that? Are they less functional or are they time based or just volume, kinda getting folks to up to date?

    Willson: It’s really just volume, right? Yeah. They haven’t really—well, a lot of them didn’t really need the change. A lot of the products that are offering this are the ones that are already SaaS based already. There will be more that are coming, of course, as things are being migrated to be SaaS based, and that effort is under way.

    But an example of Automic Continuous Delivery Director, there’s not really a time limit. It’s 10—10 active releases. That’s a lot of releases.

    Ashley: Mm-hmm.

    Willson: And you can just use it, and use it at will for that. You wanna get more than that or grow it across the enterprise or make it the standard or something, same with the Rally and Blaze CT. Oh, well, yeah, then you can buy the licenses that let you use it more broadly, right?

    Ashley: Mm-hmm. That’s a great model. I mean, I think we’ve sort of disproven the crippleware approach. Nobody likes that.

    Willson: [Cross talk], yeah.

    Ashley: Exactly, and being able to use it on enough of software production; you talked about 10. You’ve gotta be able to get a pretty good feel for what the product does that’s gonna do what you want it to do and start to integrate it into your tool chain workflow platform.

    Willson: Right, and these are 10 active releases. In other words, 10 releases in parallel, right?

    Ashley: Mm-hmm.

    Willson: Well, that’s—like you said, you should really be able to get a feel for it.

    Ashley: Yeah.

    Willson: Being able to run that many releases in parallel to each other.

    Ashley: Well, that’s awesome. That’s great to hear. I’m excited to hear about more of that coming from you, too.

    Do you have a new release coming up, here?

    Willson: Yeah. So, speaking along those lines, we have a new release for Automic Continuous Delivery Director. We’re pretty excited about this release. It is our first release that includes some ML capabilities and heuristics that are involved. Basically, what we were looking to do with this is, amongst other improvements and advances we made in the product, right, to help with continuous delivery, one of the things we looked at is that there’s significant bottleneck in continuous delivery, the methodology, which is QA or testing.

    Ashley: Mm-hmm.

    Willson: Now, as you probably know, Mitch, continuous testing is technically a subset or a component of continuous delivery.

    Ashley: Right.

    Willson: And I might argue that unless you’re doing continuous delivery, you are not doing continuous delivery.

    Ashley: Right.

    Willson: You need to be doing—

    Ashley: You need to think of continuous delivery is plan, dev, test, deploy, operate, right?

    Willson: That’s right, and you’re testing continuously, right? But the problem is, QA wasn’t really built to be agile themselves. So, they kinda became the bottleneck, not just from the way that they run, but you, as a QA person, right, testers, you build out all these tests. And so, you release this small change per DevOps per agile per continuous delivery, right? And it goes into QA and you run, you know, 1,000, 10,000 tests—and I’m not making these numbers up. Literally, a lot of our large enterprises have thousands and 10,000 tests.

    Ashley: Oh, yeah. Totally.

    Willson: Alright, so then, we’re in the waiting game, right? And maybe it takes however long for the test results to come back and then you get feedback to development. So, we found with our, a lot of our large customers, you know, the Global 2000, that this was a significant bottleneck. So, now what we do, what occurs, is that when you do that release and you’re a pipeline, right, you’re a release pipeline and it gets pushed to QA, one of the things that we do is, we look at several heuristics.

    So, we come around and say, “Alright, well, what are all the tests? What is the historical responses or outputs of the tests?” Right? How many of them failed? Which tests are flaky? How many tests are new tests? We want to actually run these tests first. So, a flaky test, for example, it ought to run at the front, and if it fails—pfft, we’ll send that feedback immediately to development or to QA so that we’re identifying these things earlier, quicker, faster, rather than having to wait on the back end for this, right?

    Ashley: Try to get to that 80/20, right? Get the things—

    Willson: That’s right.

    Ashley: – upfront that are gonna cause the most issues, find the most bugs.

    Willson: Right. So, we’re looking at all the data and intelligently figuring out the tests for you. The other thing that we’ll do is that we’ll look at the code changes you’ve made and we will map those code changes. At least in the case of Java apps, we’ll be able to map the code change to specific test suites.

    Ashley: Mm-hmm.

    Willson: So, now, when you submit that one component change, you are actually getting identified just the test runs that affect or exercise that component. So, altogether, when you put it all together, Mitch, what occurs then—now, when a change gets pushed into your continuous delivery pipeline, when it hits QA, you’re in a position to not have to run all 10,000 tests. You’re in a position now to run the high risk tests, the tests that you have marked are critical and important, right? So, those are included, that’s taken into account, too. And the test that we know actually exercised the change that you put in.

    So, you’re able to run what you have to run to ensure you have a high quality and also order them in such a way where there’s high likelihood of failure that Development is fed back that feedback earlier and faster. And so, we’re very excited about this release.

    Ashley: That’s awesome.

    Willson: Yeah.

    Ashley: Boy, gone are the days, I can remember when I would judge the quality of the release by how severe the bugs are and if we haven’t found really big problems yet, we’re not through. There’s more to come. [Laughter] You know, that was the heuristic. [Laughter]

    Willson: That’s right. Exactly. That was the heuristic.

    Ashley: That’s right. We’re far from those days, aren’t we? [Laughter]

    Willson: Well, you know, because one of the other constraints, if you think about agile and continuous delivery, right—small change and you make more frequent small changes and the “State of DevOps” report just came out, right, a week ago or this week, and it again is showing how this way, this approach is actually reducing the bugs and reducing ________ quality.

    All those things are great. But that now means one of your biggest resource constraints is time. And what we’ve found with our customers, it was time in QA. So, by intelligently assigning the tests on a run with a particular change, we’re able to shorten that down. You’re not having to wait for all 10,000 tests, you’re just waiting for the five that matter to run against that little small change and—pfft, get it shipped out the door.

    Ashley: Exactly, right. Be smart about testing, yeah.

    Willson: That’s right—be smart about testing. Exactly right.

    Ashley: Now, do you have a date when this is going public? Are you in beta now? Where are you at?

    Willson: Yep. So, if you were an on prem user of the product, it is actually GA now. It actually was up on the download site yesterday and—

    Ashley: Oh, nice.

    Willson: – it can be downloaded and you can go through the upgrade process. If you’re on our SaaS platform, you know, October 2nd, it’ll just be online working and available for you in the beauty of SaaS, right?

    Ashley: Nice. Well, great. That’s fantastic. Awesome. Well, congrats on the great release. I hope it works out very well and also the free tier brings some new customers, new people onto your platform and expand that as well.

    We have a few minutes left. I know you’re gonna be at the DevOps Enterprise Summit, correct, in Las Vegas?

    Willson: Yeah, exactly. So, we’ll have a big booth there at the DevOps Enterprise Summit, so certainly looking forward to seeing everybody wearing our Broadcom wear. We’re gonna—not to give away too much, but I think we’re gonna have some pretty cool giveaways at our booth at various times, so, you know, definitely come check us out.

    Ashley: Come early, come often for the swag.

    Willson: What—get the swag? [Laughter] That’s half of what you go for. Especially if you have kids, you know? I see some of these people, they’ve got bags full of this stuff, right?

    Ashley: Mm-hmm.

    Willson: And I’m like—yeah, you’ve got kids at home. [Laughter]

    Ashley: You don’t wear a Small—you don’t wear a Small. What are you—what are you doing, there?

    Willson: [Laughter] Exactly right. Exactly right. But we’ll have some things, a couple of the giveaways we’ll have I don’t think you wanna give to the kids, let’s just say that.

    Ashley: Okay.

    Willson: And if you’re going to the Gartner Symposium, we’re gonna be at the three upcoming Gartner Symposiums in Orlando, São Paulo, and Barcelona as well.

    Ashley: Fantastic.

    Willson: So, yeah.

    Ashley: Well, good. We’re gonna have to check in every six months or so just so we know what swag wear, logo wear to look for you in.

    Willson: [Laughter]

    Ashley: This time it’s in Broadcom—I’m kidding you, of course. But almost—it’s almost true.

    Willson: It’s almost true. Feels true. [Laughter]

    Ashley: Scott, it’s been great having you on the podcast. Appreciate you being here.

    Willson: Thank you so much, Mitch. Appreciate it and look forward to seeing you and Alan at the DevOps Enterprise Summit.

    Ashley: Absolutely. Look forward to it as well, and great to catch up with you about everything happening. Well, I’d like to thank you. I’d like to thank Scott Willson, Product Marketing Manager—or sorry, Product Marketing Director of Release Automation at CA Technologies, a Broadcom company—I think I got that right—

    Willson: You got it right.

    Ashley: – for joining us on the podcast. [Laughter] And thank you—you, our listeners, for being here as well. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chats podcast. Be careful out there.

    — Mitchell Ashley

  • Harness Adds Analytics to CDaaS Platform

    Harness Adds Analytics to CDaaS Platform

    Harness has added an analytics module to its namesake continuous delivery-as-a-service (CDaaS) platform that makes it easier to better align constrained software development resources with business goals.

    Omed Habib, director of product marketing at Harness, said Continuous Insights enables organizations to identify bottlenecks and improve overall software delivery by automatically gathering metrics such as deployment frequency, lead time, mean-time-to-restore (MTTR) and change failure rate.

    The Harness Continuous Insights dashboard

    Habib said the biggest challenge organizations face when it comes to continuous delivery is the delicacy of most IT environments. All the interdependencies between complex systems force IT organizations to rely on manual processes and custom scripts, he said, noting the process of rolling back an application whenever there is an issue can take days and weeks.

    The Harness CDaaS platform provides a more seamless approach to application delivery that automatically detects new builds in GitHub, Bamboo, Jenkins, Artifactory or Nexus repositories or any Git repository. Once the DevOps team is alerted, they can employ graphical tools to not only automate the process of building pipelines using YAML files but also leverage machine learning algorithms to evaluate the quality of a deployment and then automatically roll it back whenever necessary by accessing data from tools such as AppDynamics, New Relic, Splunk, Elastic Search and Sumologic, added Habib.

    Harness comes in three flavors. There is a Professional Edition supported by Harness and a free forever Community Edition. There’s also an Essentials Edition aimed at medium-sized companies that do not require a full set of enterprise and security features. The Continuous Insights analytics module is free for all new and existing customers of the Harness Professional Edition.

    Habib said that despite all the advances being made in terms of DevOps and continuous integration, organizations are still struggling with continuous delivery. Because many of them don’t seem to be able to push code into production as quickly as the code can be built, the pace of innovation within IT environments is being stifled. As business leaders wonder why that pace of innovations has slowed, many of them are now demanding access to application delivery metrics.

    It’s not clear to what degree providing access to those metrics will entice organizations to adopt a CDaaS platform. However, as developers and business leaders alike become more frustrated with the pace of application delivery, a groundswell for change is starting to build. Many IT leaders are now looking to automate as much of the application delivery process to prevent that frustration from morphing into a full-scale mutiny.

    In the meantime, there’s an old adage that says things measured are things done. Not everyone may appreciate all the newfound attention being paid to key performance indicators for application delivery. However, the truth is most organizations are not going to ever really solve the application delivery conundrum until somebody starts producing relevant metrics that enable them to comprehend the true scope of the challenge.

    — Mike Vizard

  • Dell Boomi Dives Into DevOps

    Dell Boomi Dives Into DevOps

    Boomi, a Dell Technologies business, today announced it has extended its integration platform-as-a-service (iPaaS) platform to include application programming interface (API) lifecycle management capabilities.

    Announced at the Boomi World 2019 conference, the API lifecycle management tools are an extension of a larger initiative to bring apply best DevOps practices to the building of APIs deployed using the Atom runtime that Boomi relies on to integrate applications and processes.

    The three additions being made to the Boomi platform include an API Proxy, a centralized mechanism managing Boomi and third-party APIs; API Gateway, a mechanism for applying governance to APIs; and a self-service API Developer Portal.

    In addition, Boomi announced integrations with Pravega, an open source data streaming software project led by Dell EMC, and the publish and subscribe software made available by Solace. Those partnerships extend an Event Driven Architecture that Boomi has defined around its iPaaS environment that includes existing support for Amazon SQS, Microsoft’s Azure Service Bus services and Pivotal RabbitMQ software.

    Steve Wood, chief product officer for Boomi, said by partnering with CloudBees to integrate the open source Jenkins continuous integration and continuous deployment (CI/CD) platform and joining the Continuous Delivery Foundation, Boomi is making a concerted effort to meld DevOps and API management to simplify deployment of the Atom runtimes on which the Boomi iPaaS platform depends to integrate applications and services.

    In general, Boomi sees a need to embrace DevOps to help customers drive digital business initiatives. To become more agile, Wood said organizations need to be able to deploy Atom runtimes faster.

    At the conference, CloudBees CTO Kohsuke Kawaguchi, the founder of Jenkins, told attendees that as they embrace DevOps they should be wary of creating CI islands within their organization. A more holistic approach to DevOps will enable organizations to harness a “gold mine” of metadata using analytics tools that will enable organizations to make more objective decisions about how best to accelerate application development and deployment.

    The sharing of best DevOps practices will also be core to Boomiverse, an end user community that Boomi launched this week as part of an effort to increase the number of IT professionals that have Boomi certifications. In the last two years, Boomi has increased the number of certifications being attained from about five a day to now more than 40 as it makes a concerted effort to increase the amount of iPaaS integration expertise available to customers.

    It’s not clear to what degree CI/CD platforms and API management ultimately will meld. It’s hard to imagine any organization trying to build and deploy cloud-native applications without having access to both platforms. In fact, most organizations now build, deploy and manage APIs as if they were a standalone application. As such, best DevOps practices are going to be required to manage APIs at scale. The challenge IT organizations now face is finding a way to teach the developers and IT operations teams responsible for building and deploying those APIs how best to work together collaboratively.

    — Mike Vizard

  • How to Implement an Effective CI/CD Pipeline

    How to Implement an Effective CI/CD Pipeline

    DevOps bridges the gap between development, operations and IT services teams efficiently. To foster a DevOps culture, implementing the right DevOps tools with the right DevOps process is essential. Continuous integration/continuous delivery/continuous deployment (CI/CD/CD) help developers and testers ship the software faster and safer in a structured environment.

    Unlike the traditional software life cycle, the CI/CD implementation process gives a weekly or daily update instead of monthly or quarterly. The fun part is customers won’t even realize the update is in their applications, as they happen on the fly.

    A Brief Insight About CI/CD/CD Terminology

    • Continuous Integration: CI is a process in which developers integrate new codes into a shared repository several times a day. This is a better approach than the traditional one, where the developer will build new codes in isolation and then integrate into the main repository at the end of the project lifecycle. The primary goal is to detect any integration bugs at the initial stage so it can be rectified quickly. It triggers a new build whenever a new code merges with the existing main repository. Test runs are performed against these new builds to check for any breakage.
    • Continuous Delivery: At the end of the CI, CD comes in. CD ensures to automate the software delivery process and commits to deliver the integrated code into the production stage without any bugs or delay. CD in the DevOps implementation process, helps developers merge the new code with the main branch consistently so they can build an instant software-ready product. It is responsible for checking the quality of the code and performs tests to check whether it can release the functional build to the production environment.
    • Continuous Deployment: The most critical part of the automation occurs at this stage of the delivery pipeline. Whenever there is an important change in the code, the corresponding build and deployment occur simultaneously. It is achieved through continuous deployment process where it allows to perform live deployment changes for every code modification that passes through the CI stage. During this stage, there is no manual intervention right from the initial code until the code is in the production stage.

    Benefits for Implementing CI/CD

    The ultimate aim for any software application is to reach its potential customers faster than ever before. This is exactly what the CI/CD pipeline offers to any business model that leverages a software process which reduces the risks in each build and helps the end product to reach the customer quicker.

    • Achieve Faster Feedback Through CI Tools: For every committed code, the corresponding tests are run simultaneously to avoid any link breakage at later stages. Faster feedback helps to check the quality and impact of the code.
    • Greater Visibility: With CI/CD pipeline setup, the whole process of new builds, test results and any issues with new builds can be analyzed. This transparency allows the developers to know which changes in the build led to the brokerage and to avoid them in the future.
    • Early Bug detects: Conducting various types of automated testing allows to identify any bug issues at an early stage without any last minute surprises. These automated tests along with few manual test runs, help to fix any issues that may arise.

    The Different Stages of CI/CD Pipeline Implementation

    To get the full benefits of the modern DevOps environment, embarking on a scalable CI/CD DevOps implementation is important. It lays a strong foundation for building an agile DevOps for your business.

    Tools for the CI/CD Process

    Tools are the magic wand that help automate a successful CI/CD pipeline and ensure a faster software delivery.

    • Open-Source Tools or Proprietary: Depending upon the budget and the client’s requirement, business can opt for open-source tools such as Jenkins for automating the CI/CD process.
    • Cloud or Self-Hosting Services: To self-host your CI/CD application, tools such as Jenkins and Cruise Control help to setup, configure and monitor the application effectively. Otherwise, you can get SaaS providers to host on cloud services.
    • Build Status: Choose a tool which embraces the transparency and visibility of the entire process through appropriate notifications, through email or other type of communication.

    Possible Challenges of CI

    • You might need a discipline strategy to address an issue by the CI/CD pipeline, otherwise the whole fast feedback is in vain. 
    • Slower builds eventually take place as newer builds keep adding to the product.
    • Failure to train the resources to adapt to new tools and patterns.

    Wrapping Up

    In this era of faster software shipping and building quick releases on the fly, adopting a more robust project cycle that accelerates the delivery pipeline is crucial. Implementing DevOps services is the optimal way to get the effective collaboration between cross-functional teams through the CI/CD process.

    — Jay Elango

  • CloudBees Advances Continuous Delivery

    CloudBees Advances Continuous Delivery

    At the DevOps World | Jenkins World 2019 conference, CloudBees released an update to the continuous delivery (CD) platform it gained via its acquisition of Electric Cloud, signaling the company’s commitment to investing in a platform that’s employed widely in the enterprise.

    CloudBees CEO Sacha Labourey said the rechristened CloudBees Flow builds on the application release orchestration (ARO) platform to further automate the last mile of a DevOps process.

    Version 9.1 of CloudBees Flow provides a path to increased visibility into how a release is progressing, including the ability to view the inventory being deployed to a given environment and deeper insights into all the sub-pipelines that make up an overall release.

    The latest release also provides more granular control over release pipeline execution, customizable dashboards within the platform’s Release Command Center and data archiving capabilities that make it easier to comply with regulatory mandates.

    Labourey said that while companies that have developed commercial software-as-a-service (SaaS) applications tend to have very mature DevOps processes, most enterprise IT organizations are still defining the best DevOps practices they want to implement across their organization end to end. CloudBees Flow provides a continuous delivery framework for automating the deployment of applications at enterprise scale that complements the Jenkins continuous integration/continuous deployment (CI/CD) platform, he said.

    Labourey noted the goal is to eventually unify continuous delivery processes across multiple platforms, including the ARO platform provided by Electric Flow, the Jenkins CI/CD platform and the Jenkins X and Spinnaker platforms that are optimized for building and deploying microservices-based applications on top of Kubernetes. As part of that effort, earlier this year CloudBees became a founding member of the Continuous Delivery Foundation (CDF), an arm of The Linux Foundation dedicated to foster best continuous delivery practices.

    Most organizations that have adopted CI/CD platforms have seen varying degrees of success in taking advantage of continuous integration to accelerate the development of their applications. Continuous delivery, however, has proven to be a much bigger challenge. Organizations tend to struggle with everything from making sure they have the appropriate infrastructure resources available to support a new release of an application to debugging application code before and after it’s deployed in a production environment.

    It may be a while before most enterprise organizations truly master DevOps processes end to end. However, given how dependent on software most organizations are, increased reliance on DevOps processes has become a prerequisite for any form of digital business transformation. As the volume of software being developed increases, the rate at which updates to applications are being made also increases substantially. Most organizations are not going to be able to keep pace with that rate of change by relying on legacy software development and deployment processes.

    In many more cases now, however, the challenge organizations are wrestling with is not so much whether to transition to DevOps, but rather determining which DevOps processes to standardize on to satisfy the elevated expectations of business leaders anxious to provide customers with that next great application experience.

    — Mike Vizard