devopsy.kinsta.cloud

Tag: application release automation

  • The Right Toolchain Is the One You Build

    The Right Toolchain Is the One You Build

    One of several iterations that IT likes to go through is corporate standards for technology versus best tool for the job. We like to have standardization because it allows staffing portability between projects, but we like right tool for the job because from the moment you choose a standard, competitive factors and changes in needs make the standard less of a big win.

    DevOps is still struggling through this process, particularly in enterprises where standardization bears a bit more weight on important projects.

    The fact is that DevOps is well suited to the idea of iterating standards–somewhere between a wild west of everyone using their “right tool” and an organization dictating the tool of choice.

    Most of us use Jenkins, because it does what we need it to do. What needs doing is different from organization to organization–some use it for continuous testing, while others go all the way through application release automation. But the fact is we could iterate and replace some, or all, of the functionality we’ve decided to use Jenkins for tomorrow. Kind of like a “We have a standard that is evaluated regularly” approach.

    For those new to DevOps, the array of choices is downright bewildering. Xebia Labs has a toolchain diagram page to help those already doing DevOps, and several sources have spreadsheets/PowerPoint templates to help you work through your existing environment. While all of the options these tools try to organize for you are great for the industry to find better solutions, it makes for a confusing mess. Your toolchain could be all AWS with some scripting, all Jenkins with plug-ins or 15 different apps working independently. A surprising number of organizations are even using Git for the bulk of their toolchain.

    What matters is that you know what you have, and know what your options are. Build the best toolchain for your environment today, and keep half an eye on it to be aware when something more suited to your environment comes along. We still maintain python scripts that do a fair amount of our automation, but several toolsets in place also.

    There are objectively better tools out there, but for our purposes they are almost universally overkill. So we go with what’s best for our environment. As time has gone on, we’ve integrated more and scripted less, but it will be a while before out toolchain is actually just tools–if ever.

    If your toolset is doing the build/test/deliver/deploy cycle well enough, you’re covered. If it’s not, you need to look for alternate solutions. Even if it is, make sure you’re aware of what’s on the market and not just what’s “hot” right now. Be aware of those companies that are up and coming, maybe in spaces that are already flooded. What differentiates them, and in our environment would that differentiation matter? That’s all you need to know–there is no need for a super deep technical evaluation, unless you’re actually considering them. Just enough to know if their differences add value.

    Keep cranking out the apps that make business run. Perhaps with an updated toolchain, perhaps not. In the end, what works for your environment is all that matters.

    — Don Macvittie

  • CloudBees Acquires Electric Cloud to Advance Continuous Delivery

    CloudBees Acquires Electric Cloud to Advance Continuous Delivery

    CloudBees announced it has acquired Electric Cloud as part of an effort to extend the reach of its DevOps portfolio further into the realm of continuous delivery and application release automation (ARA).

    Announced at the CloudBees Days event in San Francisco, the deal follows CloudBees’ acquisition of Codeship, a provider of a cloud-based continuous integration/continuous development (CI/CD) platform, last year.

    CloudBees CEO Sacha Labourey said both deals are part of an effort to start rolling up many of the smaller companies providing DevOps tools that have not been able to achieve the critical mass required to operate at scale. As organizations of all sizes realize how much they depend on software to differentiate their company from competitors, he said, they are looking for a single vendor that can address all their requirements end to end. At the time of the acquisition, which closed earlier this month, Electric Cloud had 110 employees.

    Labourey added the acquisition of Electric Cloud is also notable because it extends the reach of the CloudBees Jenkins and Jenkins X CI/CD platforms to the realm of application delivery for both legacy applications and emerging modern applications based on cloud-native microservices architectures.

    While application development teams have largely embraced continuous integration, getting IT organizations to successfully implement continuous delivery has proven more challenging. The next phase of DevOps, Labourey said, will need to focus on applying machine learning algorithms to automatically discover the environment in which an application is to be deployed. Armed with those insights, it should be much easier for organizations to continuously deploy and update applications across diverse IT environments, he noted.

    As DevOps continues to evolve, it’s apparent that legacy categories such as application release management are going to be subsumed into larger software development lifecycle frameworks based on best DevOps practices. The debate many organizations are currently engaged in is determining how much they need to change their IT culture before acquiring the tools and platforms required to successfully adopt DevOps. However, Labourery said this “chicken and egg” debate overlooks the importance of getting the tools to the teams that need to make the transition to DevOps occur. Otherwise, IT leaders will find themselves advocating for a theoretical cultural change without creating the opportunity for anyone to gain hands-on DevOps experience, he noted. In short, there’s no substitute for on-the-job DevOps training.

    A consolidation of DevOps vendors is underway. In some cases, those acquisitions will be driven by leaders in a category, such as CloudBees. In other cases, providers of software development tools commonly used in legacy application environments will need to extend their reach further into the realm of DevOps. IT leaders, going forward, will need to consider carefully just how and where they want to place their bets, at a time when DevOps teams tend to add and discard DevOps tools, often with little to no regard for any larger IT strategy.

    For more insight on the CloudBees/Electric Cloud acquisition, check out Alan Shimel’s video conversation with Sacha Labourey.

    — Mike Vizard

  • Choose Your Toolstack — and Manage It — Wisely

    Choose Your Toolstack — and Manage It — Wisely

    Every DevOps toolstack has a control point, be it a bus, an app, a management app or whatever. Something always is in control and driving the other pieces of the architecture to do their part. It is a basic tenet of automation that jobs are mostly kicked off by something in the software hierarchy.

    In DevOps, most of us have defaulted to Jenkins for a large chunk of that automation. It was the center of the continuous integration/continuous delivery (CI/CD) side, and increasingly it is used to run both sides of DevOps (as I have called it previously, both DEVops and devOPS). CloudBees and recognized this trend, and an increasing amount of control and process functionality has been turning up in Jenkins.

    On the other side, there are organizations running all of devOPS from deployment tools such as Ansible or Puppet. Again, that’s not a terrible solution, since they can configure the software on the server and make sure all is ready to run.

    But neither of these toolsets was originally envisioned with the idea it would control as much of the DevOps stack as they currently do.

    If you read me regularly, you know I’m not a huge fan of this type of default control structure. There is a lot of functionality that can be laid over the CI/CD and environment automation tool. But to do some of it, the tool needs to be above the day-to-day functionality these tools specialize in.

    ARA can do it—and honestly, for a first brush at connecting the worlds represented by CI/CD and configuration management tools, is pretty impressive. Other vendors have come at it from a service bus perspective, allowing everyone to communicate through their tools and doing roll-up reports based upon what has been integrated. That’s not a terrible solution either, if it works with or can be made to work with your tools.

    ARA as a market is short on the monitoring and management end of the process when the app is deployed and clipping along. It’s getting better, and hopefully ARA that is fully integrated with monitoring tools will be the next step in this evolution, but for now most companies are handling tooling, monitoring and response to that monitoring outside of the ARA system.

    The queue systems tend to lag behind ARA in their ability to correlate and coordinate, but again this is getting better. They know only what is reported through them, so as they gain add-ons, expect they’ll handle the overall stack better.

    The long-term goal is, after all, to run from commit to release with only designed “go/no-go” checkpoints involving humans, and then to monitor, with humans getting notifications only as needed. How we get there may not be so important—or it might.

    In the market, the sand is still shifting too fast for vendors to keep up. In any given implementation, how fast you adopt all the new products is a function of choice. Use controlled chaos, changing things out for the better only when you have a quantifiable benefit and they fit into your overall architecture. Most importantly, no matter which toolset you choose to use to control the check-in-to-release cycle, new tools you introduce should integrate with it.

    So what am I recommending? That you choose a control tool that fits your specific environment and needs, and that you make certain when choosing new tools you have a path to get them integrated with that control tool. Nothing more. Don’t put a tool in charge of half or all of your DevOps toolstack just because it was there. Have a real reason, then use that reason as a gauge when adopting new tools.

    — Don Macvittie

  • Electric Cloud Applies Machine Learning to DevOps

    Electric Cloud Applies Machine Learning to DevOps

    Machine learning algorithms are being applied to advance DevOps via analytics software that Electric Cloud is making available.

    Electric Cloud CTO Anders Wallgren said ElectricFlow DevOps Foresight is made possible because of the massive amounts of data that Electric Cloud is able to acquire providing an application release and continuous delivery platform-as-a-cloud service.

    Electric Cloud applies predictive analytics against all the data it collects to identify and contrast patterns, which it then uses to generate recommendations to specific DevOps teams based on what’s occurring in their local environment, said Wallgren.

    ElectricFlow DevOps Foresight is able to generate a risk score metric that predicts the probable outcome of a release before being deployed in a production environment. Based on that score, he said, a DevOps team can decide to go ahead and deploy that code or hold it back for further testing.

    The application also will make recommendations on how to improve pipelines based on, for example, the complexity of the code being deployed, Wallgren added.

    As part of this effort, Wallgren noted that Electric Cloud has been extending the level of integration it provides with application performance monitoring (APM) tools that serve as a source of data for a predictive analytics application.

    The goal is not so much to provide a “big brother” application that will determine who should be fired, , for example, but rather reduce as much friction in the DevOps process as possible, he said.

    Being able to apply machine learning algorithms to large amounts of data is becoming a compelling reason to shift DevOps processes into the cloud, he said, adding most organizations aren’t going to be able to collect the critical mass of data required to train machine learning algorithms running in an on-premises environment. ElectricFlow DevOps Foresight enables DevOps teams to leverage a turnkey application where support for those algorithms is already embedded into the cloud service, he said.

    Wallgren noted the result should be a significant reduction in the amount of anxiety surrounding any release of an application.
    Ultimately, the question many organizations will have to come to terms with is the degree to which they want to rely on machine learning algorithms and other forms of artificial intelligence (AI) to automate the DevOps processes. For now, Wallgren said Electric Cloud is focused on predictive applications that make recommendations versus taking independent action.

    It remains to be seen just how comfortable DevOps teams will become with various forms of AI. On the one hand, DevOps teams are clearly interested in accelerating application deployments at a time when the number of applications being  developed simultaneously is increasing exponentially. On the other hand, automating DevOps processes using AI could result in flaws being propagated at a level of unprecedented speed and scale. Long term, however, those organizations that fail to embrace AI to advance DevOps are more likely to find themselves at a competitive disadvantage.

    — Mike Vizard

  • Electric Cloud and the Deployment Dashboard

    Electric Cloud and the Deployment Dashboard

    As my regular readers know, I started a series on companies that I found intriguing who were going to Jenkins World both late (a couple weeks before the event started), and ad hoc. That meant that companies I talked to on a regular basis came to mind, simply because I knew what they were up to, and whether or not they were going to Jenkins’ World.

    It turned out to be a popular few blog posts, both with readers and customers, but I was only able to fit three in before it was late enough in the event that publishing more would not achieve the goal of the series: telling you all about interesting bits to check out.

    But as these things go, the more I paid attention, the more interesting stuff I found. So I’m going to do a few “What you might not have seen at Jenkins’ World” posts to kind of get a chance to talk about other ideas that hold interest.

    Today, I’ll focus on a vendor I’ve followed but never actually used. That’s rare for me; generally speaking, if I’m writing about the product, I’ve used it. And no doubt I’ll snag a free license and put it through the paces, or have one of my coworkers do so. But for now, I’m covering them because I find what they’re doing to be of interest.

    The vendor is Electric Cloud. For those unaware, its ElectricFlow tool is in the same application release automation/continuous delivery (ARA/CD) market space that XebiaLabs (which I also wrote about at Jenkins World) XL Deploy is in. But the point of this blog is not to compare; since I have used both of XebiaLabs’ mainstream products and not Electric Cloud’s, a comparison would be unfair. I only mention XebiaLabs to help those just starting to research understand where Electric Cloud fits.

    dashboard
    Electric Cloud’s new dashboard

    Electric Cloud’s big bit at Jenkins’ World that intrigued me was its updates to ElectricFlow to allow better reporting. We all know when a build breaks, we have great systems on the AppDev side to notify the source of the breaks and project management of the issue. But as has traditionally been the case within IT, getting that information out to business leaders who have an interest in the application is spotty, at best. Combine that with the fact that what and how it is reported can vary project to project, and there always is a bit of confusion among the business about status of projects. This confusion translates to asking IT management about status and then, when IT management is wrong and a deadline is either missed or features are dropped from release at the last minute to meet the deadline, bad blood is created between AppDev/IT and the business. Since everyone at an org should be one team pulling toward success of the business, this bad blood is not good for anyone.

    It appears, from its release (I really wish I’d been at Jenkins’ World to poke the corners of this), that Electric Cloud has begun the process of bridging that gap. The growing number and complexity of toolchains means inputs are coming in from several vectors that can give indication of the status of a project. Instead of having IT management (or business management, at some orgs) run around and try to collect these disparate datasets and determine tracking for a project, Electric Cloud has begun the process of automating status collection/aggregation.

    The dashboard pictured above is a critical piece of this solution. Imagine giving business leaders access to a dashboard that doesn’t just cover the current step of a project, but tries to aggregate status from all of the steps in the DevOps life cycle. Basing this information upon release means that, over time, a library will build up that business leaders can reference to gauge this projects’ status against that of other projects, and make their business decisions based upon standardized inputs.

    This data already exists across IT, but this is the first solid attempt I have seen of a vendor tying it all together and presenting it in a manner that IT and the business can discuss with an eye to delivering. The more involved business leaders are in the process, the less friction will result, and this effort seems to be getting them more involved. While there is still much to do—note that unit test success rate is shown in the above screen capture, but unit test coverage isn’t, for example—this is a good solid start to setting up an easy-to-reference dashboard to show the business side what is going on with the project.

    There is also an API that can be used to set inputs to the dashboard that are not yet directly supported. While DevOps teams have plenty to do—and don’t really need to be developing plugins for tools that are supposed to improve quality while reducing workload—the ability to plug in whatever you need is useful for those shops where it is a priority.

    If you’re looking for a toolset that can give more information about what’s happening in your toolchain, it’s worth checking out the changes Electric Cloud has implemented, and I’ll be trying to make time in the next few weeks to give the tool a run and see how it works out. Though I see it as inevitable that the other ARA vendors will continue to increase their offerings also, sometimes it is worth checking into the early bird.

    — Don Macvittie

  • XebiaLabs Shows Off ARA, More at Jenkins World

    XebiaLabs Shows Off ARA, More at Jenkins World

    In this third spotlight on companies attending Jenkns World, another worth checking out came to mind, so I am taking a look at what XebiaLabs intends to do while there. XebiaLabs is one of the leading application release automation (ARA) vendors, and has a long history of working with Jenkins, so it’s a little more mainstream than the other companies I’ve written about.

    But the thing is that Jenkins’ and XebiaLabs’ tools do work well together, offering an end-to-end build/deploy process that is repeatable and can be repurposed for different targets or different applications.

    While Jenkins handles CI/CD, XebiaLabs ties in the deployment pieces to complete the picture and make a streamlined system. When I experimented with XL Release and XL Deploy, I used them to call Jenkins as part of the release process. Interestingly, you can also call them from within Jenkins, which dovetails well with what another vendor I looked at—CloudCoreo—is doing. The ability to control the process from Jenkins is nice and has uses in the early development phases, but XebiaLabs raises the level of release management—something Jenkins is not doing (yet). The bit that ties CI/CD to automated deployment should be running the show, IMO. But I can imagine environments where kicking off all the build/release cycle from within a Jenkins job would be the preference.

    Anyway, on to what XebiaLabs is doing at Jenkins World!

    Key for XebiaLabs this year will be showcasing its DevOps platform, which is both XL products and talking about how the company is advancing integration between these products and Jenkins. Its recent Templates as Code (the link is to an earlier version, from January, but talks about its goals with Templates as Code, so it’s a good start if this is new to you) implementation that made it easier for developers to work with its products is being enhanced, and I’d love it if someone took a look at it and told me what they think. I can probably get someone at XebiaLabs on the phone to talk about it, but real users often have a better take on suitability in the wild.

    The important bit for many of you will be XebiaLabs’ Periodic Table of DevOps Tools, which I know several people would love to have as a poster in their office. For cool factor, it’s hard to beat. The company will have tubes with the periodic table available, so drop by to snag one. Last year it ran out of them relatively quickly, so be early. Bonus points to anyone who snags an extra and sends it to me for my office (ha ha).

    Aside from the Periodic Table of DevOps, XebiaLabs also will have copies of “The DevOps Handbook,” which I recommend. For those who haven’t read it, the format is different than “The Phoenix Project,” but it is the next logical step in that progression. Finally, the company will have its own book, “The IT Manager’s Guide to Continuous Delivery,” which I haven’t read, but having read XebiaLabs’ corporate blog for a while now, I predict will have some good ideas in it.

    I admit an interest in how recent changes to XebiaLabs’ DevOps platform improve the experience across the org (or don’t improve it). I haven’t used its tools since the new “pipeline as code” changes were introduced in January, so I honestly have no idea. If you go and stick around for a demo, let me know what you think.

    — Don Macvittie

  • Don’t Underestimate the Work

    Don’t Underestimate the Work

    It is relatively common in human endeavor to attempt to figure out how much work will be involved in a project, and be wrong. The more complex the work being done and the organizational system doing it, the further off estimates can be. This was one of the drivers for both Agile and DevOps: to take smaller steps with less dependencies and complexity.

    The complexity problem is true in the path to application release automation (ARA) as well. ARA merges continuous test/continuous delivery with deployment automation, but both of these toolsets are complex and continuing to evolve. When you think about it, it is somewhat amazing that ARA can handle the breadth of functionality it is covering, while both sides are shifting and growing as well as it does.

    Construction Crane
    Construction Crane, compliments of Pixabay

    When you approach ARA, you should make certain you have a handle on the amount of work that it will take to get the system up and running. It’s not simple, even if you’re already using a full CI/CD environment. But it’s worth the work, so here are some of the things to watch out for.

    Multiple Targets

    First on the hit list is on the deployment side. One of the strengths of ARA is the ability to deploy to any environment. The ARA system has to know about each environment in enough detail to enable deployment on it. It must know how to deploy servers, where to get OS, what needs to be added on to the OS, and how to get the application onto these systems. Increasingly, programmable network elements and security configuration fall into this category also. While tools such as Chef and Terraform can help in this regard, if you’re not already using them, they’ll have to be configured if not already, and then linked into your ARA tool. Understanding the path from here to there is critical to early success with ARA.

    Databases

    This is one of the more vexing problems. While most ARA tools offer the ability to configure databases and database connections, your datasets generally don’t hop around so easily. So if you’re testing and deploying on separate networks, you’ll need to make sure that the relevant tables are on those networks. This struggle impacts moves to the cloud, changes from a fully test network to production or any other change that requires the database server be accessible when it hasn’t been in the past. The work to solve these problems is pretty wide. In some cases, such as purely internal or purely cloud, merely routing from the relevant app instances to the database server will do it; but, in the case of across-the-internet changes, it will take a lot more work. Make certain you understand what challenges you will face before moving.

    Tooling Sets

    Much of the external needs of an application are baked into the app build process through tools such as NPM or Git. But those tools don’t cover everything necessary for the entire app ecosystem. Agents, per-tool databases, small tools used occasionally—make certain you have a list of what makes the app work, and make certain they’re configured to be built in by the ARA tool. This sounds obvious, but watching a team learn by trying to deploy and fix broken parts only to do it again is not only painful, it also leaves a “Did we get everything?” impression. I saw one app break on deploy because the team didn’t include curl. Yes, curl in the deployment. Test had it in the environment, production did not.

    Get an inventory of both application development dependencies (libraries, etc.) and deployment dependencies (databases, reporting tools, agents for monitoring, etc.), and save yourself some pain.

    Decrease Your Work by Asking Questions

    ARA gives you a repeatable build/deploy process that can be used to target the environments you need while reducing manual scripting and steps. But before you throw in, sit with your vendor’s tech people and ask them to walk you through stumbling points, they likely know far more gotchas than I do, because it’s their job, and unless you got the new guy for an SE, have probably seen more. And getting ARA up and fully functional quickly allows you to focus on other DevOps needs, such as improving automated testing.

    — Don Macvittie

  • appOrbit: End-to-End Hypercloud

    appOrbit: End-to-End Hypercloud

    As cloud and DevOps have heated up, enterprise need for cloud portability and deeper DevOps integration have become pretty clear. The need for portability to avoid cloud lock-in has been a desire of enterprise cloud users from day one. A variety of people are attempting to address this need, but the market is still very much evolving.

    In the area of DevOps integration, the two topics currently causing struggles are security and networking. Continuous deployment inevitably requires both to be part of the DevOps package, and those are the newest additions to the field, so it is still maturing.

    Enter appOrbit

    appOrbit recently came out of stealth mode with an overarching architecture to enable hypercloud and extend the DevOps process across the entirety of the dev/test/deploy ecosystem. The idea is to offer a platform that doesn’t care what languages or deployment tools you use, or even what databases you’ve tossed data into, and covers the process from first line of code to management and monitoring post-deployment.

    That’s a big claim, so I got on the phone with appOrbit to poke around a bit. Better would be to take the time and use the toolset, but I’ll settle for our questions about the traditional weak spaces in the process, and about how they achieve some of the company’s claims. For now.

    My first impression was that this was application release automation/application release management (ARA/ARM), and Rahul Ravulur, CEO of appOrbit told me I wasn’t far off; I just wasn’t thinking big enough. A large part of the process is ARA, but additionally, appOrbit worries about networking, security policy and long-term monitoring and management, all while offering deployment portability.

    Finally, the End Game is in Sight

    From the beginnings of the Ops side of the DevOps movement (what I like to call devOPS), the end goal was pretty obvious: to improve the entirety of the process. It was clearly going to take time—good network engineers are wizards that can make a network do astounding things—and we had to figure out how to make that more repeatable. On the DEVops side, repeatable was relatively painless: We already did a predefined sequence of steps over and over; the point was to break them into smaller iterations and automate what was ripe for automation. Much of Ops was the same, but networking and security had many more variables to take into account, and less history of “here’s a prescribed sequence, do it.”

    If appOrbit can do as it claims—and its customer list includes some customers I’ve worked with that probably wouldn’t be there if the product was vaporware—then we’re seeing the culmination start. The culmination will include limitless portability, sort of a “we don’t care where you deploy, just tell us and we’ll do it”; it will include development tool agnosticism—“We don’t care what tools you used, we’ll deploy it”; and it will include complete solutions—“We’ll move your data, we’ll move your app, we’ll configure the target network, we’ll run the security checks relevant to the target platform.” It sounds like appOrbit has traveled quite far down that path already.

    What, Exactly, Did You Intend?

    One interesting bit appOrbit talked to me about and I’d like to take out for a spin is the idea of adding “intents” to security and networking. Tell it what you’re after, and through a combination of built-in functionality and plug-ins it will deploy your application as you intended. For things like opening a port, this seems pretty straightforward, but security and networking are complex topics. What is/isn’t covered by security policies/intents? What if my intent is for the system to create a VPN, lock down all the ports, then open just a few and connect the VPN back into the data center over an encrypted port? Who manages certs? Where does it get the credentials to get back into the data center? What happens if I take this whole VPN-based deployment and decide to put it inside the data center after all? Do I have to rework the networking intents to remove the VPN? The questions are endless.

    But assume this is the beginning of a road that truly can end up with “deploy anywhere, and deploy as you intended.” That’s what we’ve been waiting for, and it’s inevitable, so I for one am glad to see us set off meaningfully down the path.

    Improvement Makes Movement

    The mere act of someone talking about having pulled all this together will be good for customers. Ravulur’s stress that “a lot of what we do is ARA” will no doubt make ARA vendors step up their attempts to be as inclusive as appOrbit is, and the market will move forward. appOrbit’s use case of “legacy app migration” without changing the app alone offers an avenue for enterprises to begin to move to new platforms. That in and of itself will be a help to the huge number of enterprises that want to move to a more modern environment but aren’t ready or able to rewrite entire systems. And again, it will spur on competitors—in this case in the application provisioning space, most likely—to try and implement similar functionality in a relatively short time frame.

    Beyond Hope

    In a nutshell, I hope that appOrbit can do all that it claims, but even if it falls short in some areas (I honestly have only touched on a few of the areas it has pulled together; there’s a lot here), it is a step forward, and I think the company will drive the market more toward the end goal of application portability from both the Dev and deployment sides, while automating a more complete solution.

    To me, that’s all good. Not everyone is pure cloud, and a far fewer number want to be pure public cloud brand X. The automation tools I’ve been knee-deep in all have been massively complex under the covers, and no doubt this one is, too; simplifying automation so it is easy to adapt to a given environment is a huge part of the task these tools perform. Figuring out the weaknesses is what we customers have to do, but in the end, we’re moving forward.

    I, for one, will look for a chance to play with appOrbit’s toys, validate some of its claims, and see how well it suits enterprise needs. But I don’t have a timeline, so if you’re interested, you should check them out yourself.

    — Don Macvittie

  • Application Release Automation: Why and Not

    Application Release Automation: Why and Not

    But what if it has no tank?

    You have a classic car. You’re in the middle of restoring it, and it looks mighty sweet. Paint is polished, wheels are stock, hubcaps (or spokes) are shiny, engine is completely restored to original spec.

    But it has no gas tank.

    A bit of a stark comparison, but that’s where we’re at with application release automation (ARA)—at least in terms of portability. And where we’re likely to stay.

    Hold on, I’m a Fan

    Before the DevOps aficionados get out the torches and pitchforks, let me be completely clear that I’m a huge fan of ARA, and explain again why.

    Tools such as Jenkins allow DevOps teams to automate the entire build/test stack—or as much of it as their organization requires. That is a huge step forward, for all the reasons we’ve covered in the past, including the one I think is often overlooked or underemphasized: With frequent build/test feedback, the code is still fresh in the developers’ head when they learn of problems. Most of the time, they are fixing before moving on to the next task, which is a huge plus compared to waterfall, where many problems show up long after the developer in question has forgotten what the code is doing because they’re off on other things.

    Likewise, tools including Puppet, Ansible and Chef (to name the top few) allow DevOps and security to set standards via script, and use those scripts to deploy over and over. This has all the benefits we’ve discussed, too: speed of delivery, reduction of human error, repeatability that becomes stability, etc. This gives operations the ability to answer, “Is server X set up to do this new thing?” by looking in deploy scripts, and quickly updating things if the answer is no, but X will be required going forward. That’s one of my favorite bits of application provisioning.

    Riding the Gap

    For those unfamiliar, ARA simply bridges the gap between DEVops and devOPS—tying code being released to platforms and configurations it will be released under. It has the ability to rapidly re-target a release to a new environment, and it can do predictable and repeatable releases, offering the benefits of application provisioning for the actual release segment. Most tools do this by tying together your favorite build tools and provisioning tools, and giving ops a control panel that can manage the process end to end.

    The benefits are huge, particularly for Operations and Security (which have another place to standardize and insert essential monitoring). And also for Development, because it offers one further step in testing and, by doing so, reduces the surprises six months down the road when you’ve forgotten what

    Bubblegum += 10

    is in your code for.

    So don’t take my intro as offensive. I am a fan. But I’m a realist. There is no panacea.

    ARA: It’s About the Data (As Always)

    The two weakest parts of most ARA systems are server provisioning and data issues. Server provisioning is setting up OS/hardware, and many ARA systems tend to assume you magically did elsewhere. This problem is only an issue in highly physical environments and there are tools to handle the problem—they’re just not integrated well with most ARA systems. Data issues are the bigger problem.

    It’s cool that we can drag and drop a couple boxes and magically switch our deployment from inside the data center to a cloud provider in the time it takes the ARA to build/deploy. But we all know that’s not how the world works. Now you have an application, complete with database that is correctly configured and security that does AAA solidly … and no data.

    “Just move the data then!” the choir sings. No, that’s really not how it works in an enterprise. Data itself is an object of security and compliance, and some source databases are so massive that moving them is a nearly impossible chore in and of itself. Amazon tips its hat to this fact with its import/export service.

    This was the reason why I gut-reacted with an eye roll to the “No more physical data centers!” crowd back in the midst of the hype. The amount of data stored in data centers is staggering, and often not portable at all. Add to this that such data isn’t going to reduce, and we have a quandary.

    What About Moving Forward?

    Sometimes, it is necessary to accept that the current state is not changeable, but take steps to improve the future state. I don’t see this as a reasonable approach in this case, because the rules of data aren’t changing in a way to change future state in a positive way. We’re generating more data every day, and that data will end up stored somewhere. Be careful where you store it; think long-term strategic. Having ARA doesn’t magically make that data portable, so make sure that where you store it today while it’s small is where you’ll want to store it in five years, when it is a massive, largely immobile asset.

    What to do … What to do

    Use ARA to multi-target all of those apps that are portable without terabytes of data, and make sure data generation/collection/analysis apps are on the architecture you will want them on moving forward. ARA offers a ton of other benefits, so data portability isn’t a deal-breaker—or even a significant negative, since you probably already knew some datasets weren’t going anywhere—but don’t expect miracles out of it. It can’t make your large datasets portable, so don’t expect it will. And use it to target the platform your organization feels is most appropriate for apps that will generate or collect a lot of data.

    — Don Macvittie

  • Continuous Delivery vs. Continuous Deployment

    Continuous Delivery vs. Continuous Deployment

    I am often asked, “if we are using a continuous integration (CI) server and adopting a continuous delivery pipeline, where does continuous deployment fit in?” Good question. In a nutshell, continuous delivery engines such as CloudBees or Blue Ocean are designed to trigger the execution of CI workflows across the dev, test and prod environments. Continuous deployment is called as part of the CI workflow to do the actual release of code out to endpoints. Continuous deployment can be managed by application release automation tools or supported by one-off scripts. Regardless of how sophisticated the deployment step of your CI workflow is, it is still continuous deployment.

    To understand both continuous delivery and continuous deployment, one must go back to their roots, continuous integration. CI is a key component of Agile practice.  Agile developers understand the importance of adopting a methodology that can manage smaller incremental software changes to release software, and therefore business value, to end users quicker and cheaper.  The activities of deploying to testing and production historically have been in the hands of testing and data center teams, separate from Development. But in the Agile practice, these activities cannot be separated from development. The concept of separate development, testing and production teams is a waterfall concept, not an Agile concept. In Agile, everyone is on the same team. This means that testing and production teams must become part of the Agile process.

    Mastering Agile’s last Mile

    Ultimately, the goal of continuous delivery is to accelerate release cycles and get new code out to production fast. However, for most companies this is not happening. Developers and testers may have embraced continuous delivery, but when it comes to production, the code is moved to a staging area where it languishes until production is ready to perform the update. The last mile of Agile is not achieved. And we are back to where we started: waterfall.

    There are many reasons for the production roadblock. Lets’ review the top four.

    • Agents: Both open-source and commercial CI servers are agent-based. An agent based system works fine for developers and can be tolerated by testing. However, production teams are not that excited about installing yet another agent on to the production end points. For this reason, production team use their own method of deploying code. Therefore, the deployment scripts used for releasing code to dev and test are not used by production. The way they see it: Production does not want a deployment process that requires them to re-configure their data center environments with agent from a development tool.
    • Scripts: Production teams want input and visibility. One-off scripts obfuscate the deployment process. For this reason, production teams will write their own scripts. Scripts simply do not have the intelligence needed to meet the audit, rollback and transparency requirements needed by production teams. Production teams perform many steps manually. This takes time and cannot be done in an agile cadence. The result: Great code languishes in staging areas. Production stays several releases behind what continuous test has approved.
    • Cost, cost, cost: Most of what developers create in a continuous delivery workflow comes from open-source or consumption-based licensing models (think Jenkins and Jira). Tools that can achieve continuous deployment such as application release automation solutions are far to expensive for one development team to acquire and incorporate into the CI workflow. These types of tools are sold at the CIO level and cost upwards of $250,000. Production teams are often hesitant to purchases these tools, as the high cost equals high risk. And ‘one ring to rule them all’ does not work. This type of operational tool acquisition is waterfall-based and does not fit into the leaner Agile DevOps tooling. The result: One-off scripts continue to be used and dev and test. Production does not adopt agile.
    • Sustainability: During waterfall, a production release was performed as infrequent as two times per year, or at most once per quarter (considered aggressive). In other words, production is staffed to support a production release on an infrequent basis. With agile, the demand for production releases increases 10-fold. Instead of doing at most four releases a year, they may be required to do four releases a month. Production cannot keep up the agile pace. They are staffed for waterfall.

    Automating Continuous Deployment: Key to Maturing Continuous Delivery

    Continuous delivery cannot be successful without continuous deployment. If you want to roll code out to end users faster, the deployment process itself must be modernized. Using the same one-off scripts that were used in the waterfall approach will not achieve your CD goals.

    Continuous deployment automation is performed by a new set of agile DevOps tools called application release automation, or ARA. ARA solutions are designed to support a model-driven software deployment that allows development, test and production teams to use the same process without the need for one-off deploy scripts. ARA adds all of the features and functions needed to support continuous delivery and data center deployment requirements. ARA is designed to fully perform the heavy lifting of software releases including application packaging, release versioning, database updates, server configuration management, calendaring, roll-forward, rollback, security access and auditing.

    ARA solutions are called by a templated CI workflow that is defined by the development team. The workflow is moved up the pipeline and adapts to the changes at the various pipeline stages (System Test, Integration Test, Pre-Production, Production, etc.)  Because the process is driven by the ARA tool and not a script, the changes are automatically addressed across the pipeline reducing the workload for all teams and supporting frequent changes that can be easily traced and audited down to the server inventory level, including the production environment.

    Developers, Get Your Hands on Deployment Automation Tool       

    To achieve a repeatable CD pipeline that supports production, developers must embrace the automation of continuous deployment at development. The dysfunction however is the outrageously high cost of ARA tools. Developers don’t buy expensive operational solutions. More ARA solutions must be offered on a consumption-based model or offered as open source with the ‘out of the box’ integrations into CI/CD. When considering the purchase of an ARA solution, look for agentless models that can be implemented one project team at a time. Embracing this level of corporate process change must be done project by project. The operational big bang approach does not work well in an agile practice. Not everyone can use the same solution. However,  if done correctly, there are big benefits.

    ARA is a process that strengthens the foundation of the continuous delivery pipeline and is core to the agile DevOps initiative.   It facilitates agile practices by allowing the testing teams and data center teams the tools needed to become more agile and accept the frequency of changes being pushed across the pipeline by Development. Ultimately, the goal is repeatability across the pipeline, pulling together Dev and Ops.

    About the Author / Tracy Ragan

    Tracy Ragan is CEO and Co-Founder of DeployHub. Tracy has extensive experience in the development and implementation of business applications. It was during her consulting experiences that she recognized the lack of build and release management procedures for the distributed platform that had long been considered standard on the mainframe and UNIX.  Tracy has worked with hundreds of development teams in implementing a team-centric standardized build to release process. Connect with her on LinkedIn.