devopsy.kinsta.cloud

Tag: continuous delivery

  • Back to Basics

    Back to Basics

    We here at devopsy.kinsta.cloud do sometimes suffer from The Curse of Knowledge. We write about DevOps regularly for an audience that is doing or managing DevOps. We assume knowledge, but there are still a fair number of people and organizations who are unclear about some of the terminology/technology that we talk about.

    So if you are a regular reader of my blog, this might be a redundant post—but read on because it might have info you haven’t had a reason to consider yet.

    I’m going to start with the obvious—how most readers got here to begin with: DevOps. DevOps is automating the build process so that builds are automated and repeatable. Teamed with Agile development, DevOps means that development teams can rapidly iterate through development and generate regular updates to their applications. Everything else in this blog is based on the premise that it is running in a DevOps environment.

    Continuous integration: Typified by Jenkins, continuous integration (CI) is the part of DevOps that runs the automated builds. It includes reporting and defect resolution only in the sense that it feeds into other systems that track defects. With CI in place, a developer or DevOps engineer can say, “Okay, ready to test a build,” and with one command, can kick off a build that will result in a finished artifact. Or result in a built product, anyway. ‘Finished’ is optional, and the target of CI is not generally a running application.

    Continuous delivery: One of the most confusing things for new DevOps people is CD. The way that the space evolved, there are actually two things that CD could stand for; continuous delivery–automated build of the complete application —or continuous deployment—delivery of a running application onto infrastructure. Continuous delivery is straightforward and means all the bits of the application are code complete–or at least the current state of the application is complete enough to build an application. Continuous deployment is much more convoluted. It might mean deployed to a development environment for developer-level testing or a test environment for running automated (continuous testing) tests on or in production. It might be a staged rollout, where users are siphoned over, or it might be a hard rollout where the old version is replaced by the new in a manner similar to ripping a Band-Aid off.

    Continuous test: Automated testing is at the heart of continuous test (CT), and it is only now becoming a real possibility for most short-staffed enterprises. Advancements in machine learning (ML) mean that tests can be run, results filtered to eliminate false or duplicate results, and IT staff is only notified of the important bits. Unlike traditional testing, staff is required only to create the tests and to look at meaningful results.

    Infrastructure-as-Code: Infrastructure-as-Code (IaC) is the ability to define all relevant elements of infrastructure with text files. Often this is done in YAML and sometimes in a variety of other formats. The idea is that infrastructure provisioning can be on-demand and adaptable. It is certainly more agile to change a text file from port 80 to 8080 and then run a command to process the text file–now the port is documented and whenever needed the command can be re-run to move to a known state. IaC largely relies upon software implementations over physical. While the idea of software-defined networking (SDN) has fallen out of favor, the underlying principles are everywhere and part of IaC, for example.

    GitOps: All the rage these days, GitOps is probably best defined as applying DevOps to operations. That does sound weird, but I like to break it up as “traditional DevOps is DevOps, while IaC (to a lesser extent) and GitOps (to a huge extent) are DevOps.” The point being that GitOps uses the text files generated in IaC and worker nodes generally designed for continuous deployment and then performs operations tasks based on those text files. If IaC defines the entire environment that an application needs and DevOps defines all of the sources that an application is composed of, bundling the two together will enable full-on automation from conception to decommissioning. When a new version of a source file or configuration file is checked into Git, the system then makes certain that every instance of the application is updated with the new version. Of course, this process, like every one listed here, is far more complex than that in implementation; we are talking about ‘what, not how’ at this level.

    All of this really is the very tip of the iceberg, but that was the goal here – to offer readers a place to start if they’re finding themselves looking at DevOps for the first time. As you dig deeper, things like DevSecOps and test driven development (TDD), or defect tracking and Agile methodologies start to play into the landscape, and maybe I’ll write an intro bit for those also. But this time, we’re out of space.

    As always, keep rocking it. No matter which or how much of the above you are using, if the organization’s applications are up and running, that’s you. And you deserve more kudos than you are likely getting. But keep grinding through—the rest of us get it, and thank you.

    Image source: Photo by Towfiqu barbhuiya on Unsplash

  • Best of 2022: CI/CD is the New Lock-In

    Best of 2022: CI/CD is the New Lock-In

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Welcome to 2022! Let’s start this year’s blogging off with a bang, and point out that we are in the process of creating the biggest lock-in that we have ever had. And I do mean ever. Maybe the hardware lock-in of the old days where vendor A was incompatible with vendor B was worse, but at least that one we acknowledged when we signed the contract. This one is growing on us as I type.

    Our DevOps environments in 2022 cannot run without what I like to call the “toolchain controller”: GitLab, Github CI/CD, Atlassian, CircleCI, Jenkins—whatever you are using. Like you need some form of faucet or flow control to make running water work, you need the CI/CD environment to make DevOps work.

    You. Can’t. Live. Without. It. And just like any other vendor solution, CI/CD vendors are not going to be in a rush to help you move to a competitor. It won’t be easy or cheap to switch, largely because we are moving everything that might have been on a computer that once had developed code running on it into the toolchain.

    Sooner or later, we’ll back off the kitchen sink definition of “What is DevOps?”, but I predict even then we will have to answer “…A lot of what we do,” because DevOps is, by definition, end-to-end. It is about the process and all the steps from design to production.

    No matter how long or complex the process through which an organization’s CI/CD tool runs, a plan must be in place to replace it. A workable plan, not a check box plan. When Atlassian decided they preferred cloud-based customers, their customer base was shocked. Atlassian was wise enough to leave an option for customers who really had to have an on-site solution, but it is not difficult to imagine them phasing that option out, or to imagine another vendor dropping on-site support altogether. Some of the more competitive offerings in the space—GitLab springs to mind—are online-only already, making that option more appealing to other vendors as it’s now proven viable.

    So, have a plan. This is more important, IMO, than cloud vendor lock-in. Cloud vendors are a small community, and each understands the others, so if push came to shove you could find help moving between the big three cloud vendors. There are dozens of DevOps master controller-type solutions in regular use, and some of them are not at all CI/CD solutions (application release orchestration tools and software infrastructure management tools are two areas doing CI/CD duty at some orgs, for example), so there is not going to be much help moving between them unless you manage to find a very specialized skill set that matches your desired move.

    So, have a plan. Yes, I am indeed repeating myself. Know what you’re going to have to do before you have to do it. Include what to do if the master DevOps controller goes down. Because it will, sooner or later.

    And keep rocking it. Protect your masterworks by protecting what builds them. And keep rolling out the tools your users need. It’s a new year—learn a new skill and use that to turn out even more cool stuff. I haven’t picked a new skill yet, but I’m taking that last bit of advice myself. And again, in the new year, thank you, for all those who don’t know to say it.

  • Why IT Teams Need Continuous Improvement

    Why IT Teams Need Continuous Improvement

    In the dynamic world of software delivery, an ‘if it’s not broke don’t fix it’ philosophy won’t get you very far—even when your software and systems are working as planned. 

    Software is more complex than ever and innovation is exploding across markets. To keep up with constant innovation from your competition in a global marketplace, you should always be thinking about how to improve your products and services. 

    The teams and organizations focused on continuous improvement simply outperform those who settle for the status quo and fear the unknown. Let’s look at why continuous improvement is important in IT organizations; how to avoid common mistakes when measuring success and tips for getting started. But first, let’s define what continuous improvement is.

    Defining Continuous Improvement

    Continuous improvement is incrementally improving a project or process several times based on feedback. Feedback can come from various sources, including users and automated testing.

    Advantages of Continuous Improvement

    Making small changes over time offers many benefits when compared to a “big bang” change. Often, a “big bang” change is made with little to no feedback until it is almost too late. 

    By making smaller changes, a team can try something, listen to feedback and adjust. If a change is poorly received by end users, little time was spent working on it, so it can more quickly be completely reworked or scrapped altogether. This encourages experimentation with the safety net of knowing nothing is permanent.  

    Think of it like swimming from one end of a murky lake to another. You could dive underwater and not come up until you hit land and, hopefully, you are in the right place. Or, you could periodically pop your head above water, check your bearings and adjust course.  

    Who Benefits?

    Today, it’s hard to imagine a situation where IT teams wouldn’t benefit from adopting a continuous improvement methodology.  Any IT team whose responsibilities include writing software and delivering it to users benefits from continuous improvement. Smaller, incremental changes generally mean a smaller risk of something going wrong. Making a small change to a piece of software or tweaking the software delivery pipeline to shave 30 seconds off the time it takes for each deployment environment adds up over time.

    What do IT Leaders Get Wrong?

    Continuous improvement is all about incremental changes over time to streamline workflows and cut back on waste. In the moment, those changes and improvements can be very subtle, making them harder to justify. When IT leaders don’t look at the big picture, it’s easy to miss how these small changes contribute to overall improvement.  

    For example, let’s say a team is completely focused on measuring deployment time. But the first fully automated deployment to production took just as long as a manual deployment. With a proper feedback loop, the team sees that it took just as long because there were a few misconfigured items. The next deployment takes less time, but only by a few minutes. 

    Each subsequent deployment takes less and less time. But it took several months and multiple attempts to go from two-hour manual deployments to 15-minute automated deployments. With an intensive focus on deployment time, this may not seem like a significant improvement given how long it took to get there. However, in this scenario, the team was so focused on deployment time that it missed other important measurements, such as the number of emergency fixes created after the team started automating the deployment. 

    If they examined those numbers before automation, they would have realized that they pushed out a handful of emergency fixes after a manual deployment—but, almost overnight, those emergency fixes stopped after introducing automation. Critical measurements and improvements like these are easily overlooked when leadership focuses too narrowly and avoids the “big picture” view.

    Getting Started

    When working in IT, there are many problems to solve with a finite number of people and limited time to fix them. It’s tempting to try and solve the problems at the same time. After all, you are only making small changes. 

    However, for real change to occur, you must make several small changes over time. Pick one or two problems to solve and focus on them until you reach a good stopping point; then, move on to the next problem.

    Also, know what and where to measure. With data in hand, you can take an informed approach to designing improvements. Never settle for thinking there are no further improvements because, inevitably, you will be proven wrong when your competition does it better and faster. 

    Ensure that your organization or team is dedicated to lifelong learning, perhaps by experimenting with chaos engineering to see how the system responds. This will spark important conversations and justification for improvement, as well as invaluable feedback. 

    Every IT organization benefits from adopting continuous improvement and will find that it promotes innovation and helps maintain a competitive advantage. It is easy to take too narrow a view of the small changes. But with a high-level, strategic view of continuous improvement, leadership will see the benefits. 

  • Building Higher-Quality Software With Open Source CD

    Building Higher-Quality Software With Open Source CD

    Business is accelerating, and experience– for customers, partners and employees–is everything. This means nearly all applications need to be enhanced with new features, security updates and bug fixes on ever-shorter cycles. But isn’t rushing new code into production, especially in cloud environments, a recipe for mistakes, security vulnerabilities and user frustration? Not if the right approach is taken.

    Continuous delivery (CD) enables development teams to rapidly and regularly deploy software updates into production systems without jeopardizing user experience or creating security risks. Battle-tested open source CD orchestration solutions, including Spinnaker and Argo, provide a cost-effective way to deliver secure, high-quality software at massive scale to multi-cloud and Kubernetes environments.

    What is Continuous Delivery (CD)?

    Most software development teams suffer from quality issues related to outages, tracking down bugs and security vulnerabilities, complex upgrades, release rollbacks and more. According to a 2020 report by the Consortium for Information & Software Quality™ (CISQ™), software quality suffers as companies rush to add more value at greater speeds. In 2020, the cost to companies was $2.08 trillion in the U.S. alone.

    CD relies on a framework of stakeholder collaboration, process automation and continual and rigorous risk assessment and feedback to ensure a smooth, high-volume flow of high-quality code is deployed to production systems. When done right, CD reduces software development risks by enabling development teams to deploy changes such as new features, configurations, bug fixes and even experiments into production safely, quickly and sustainably. It also reduces costs associated with software deployments, failed releases and customer frustration and attrition.

    With effective CD workflows in place, development teams gain confidence and are more productive, delivering better products faster while eliminating the frustration of missed release dates, management wrath and the blame game associated with software bugs and vulnerabilities making it into production.

    Open Source CD Solutions

    Prior to the rise of open source CD solutions, companies often relied on point automation using scripts. These could improve efficiency a bit, but when companies moved from the monolithic architecture of a mainframe or on-premises servers to a microservices-based production environment, the scripts could not be easily adapted or scaled to cope with the more complex environment. This led to the formulation of continuous delivery orchestration solutions that could ensure code updates would flow to their destination in a repeatable, orderly manner.

    Two highly popular open source CD solutions have emerged, Spinnaker and Argo. Spinnaker was developed by Netflix and extended by Google, Microsoft and Pivotal. It was made available on GitHub in 2015. Spinnaker creates a “paved road” for application delivery, with guardrails to ensure only valid infrastructure and configurations reach production. It facilitates the creation of pipelines that represent a software delivery process. These pipelines can be triggered in a variety of ways, including manually, via a cron expression, at the completion of a Jenkins Job or other pipeline and other methods. Spinnaker also provides cluster management, as well as visibility into an application’s cloud footprint, letting users resize, delete, disable and even manually deploy new server groups using strategies like blue-green deployments.

    Argo CD, a container-native deployment engine for Kubernetes, supports CD pipelines, enabling the automated deployment of applications within Kubernetes. Introduced in 2018, Argo CD utilizes the Argo GitOps Engine, an open source library that implements core GitOps features. It allows users to manage, automate and audit the software deployment with Git as the source of truth. Features of Argo CD include drift detection, the analysis of the health of application resources and a real-time view of application activity.

    As open source software, both solutions offer all the benefits that the open source model offers, including low start-up costs, rapid and continual innovation and paid support when it becomes necessary.

    A CD Automation Success Story

    Symphony provides a cloud-based collaboration platform for financial institutions that are highly regulated and render services to millions of customers, so the solution must meet rigorous standards for security and regulatory compliance. The company wanted to enable a multi-tenant system to improve performance and reduce the cost of operations for each client. However, the existing software delivery system created bottlenecks in integration testing, long triage times and manual handovers of releases to site reliability engineering (SRE). The ever-growing number of delivery pipelines and software delivery environments also increased infrastructure costs and the burden on human resources, making it difficult to deliver features faster and ensure compliance at scale.

    Symphony determined it needed a completely new CD solution supporting infrastructure and software delivery workflows that they could retrofit into their existing platform. The solution needed to support infrastructure-as-code, pipeline-as-code and configuration-as-code, while providing visibility, auditability and faster approval processes. Symphony opted for a CD solution that harnessed the power of both Spinnaker and Argo to automate the entire end-to-end CD process, including pipelines for infrastructure, deployment, testing and promotion to production deployments. With the solution, Symphony was able to slash the time required to onboard new environments by 98%–just 10 minutes to get the infrastructure and platform ready for the client. This also allowed for fast and frequent changes.

    With automated CD in place, the company enjoyed significant cost optimization through automation. It was also able to increase security and compliance through automatic policy checks that continually enforced compliance across the stages of each pipeline–without compromising delivery speed.

    Getting Started

    As you review potential CD solutions, ensure they can deliver the required level of:

    • Ease of setup and configuration
    • Visibility and collaboration
    • DevOps tools integration and extensibility
    • Built-in deployment environment support
    • Security and governance
    • Workflow flexibility
    • Performance, uptime and scalability

    Get an Expert Assessment

    While the benefits of a CD solution are enormous, deploying one is not trivial. It pays to make good choices to get it right the first time. A professional assessment of your existing environment and processes can help you in several ways, including:

    • Exposing your current silos
    • Identifying the bottlenecks in your software delivery process that can be automated
    • Identifying productivity improvement opportunities for everyone involved in the delivery journey
    • Giving you the insights you need to make an informed decision about your CD solution.
    • Providing advice on best practices that can transcend the deployment process to the next level of efficiency and quality

    If your company requires the rapid delivery of secure, high-quality software releases, the time to deploy a continuous delivery solution is now.

  • Octopus Deploy Tightens Integration With GitHub Actions

    Octopus Deploy Tightens Integration With GitHub Actions

    Octopus Deploy announced today it has tightened the integration between its automated deployment platform and GitHub Actions continuous integration/continuous deployment (CI/CD) platform.

    Harsh Sabikhi, senior vice president of revenue for Octopus Deploy, said GitHub Actions for Octopus Deploy v2 adds support for a push-build-information-action capability GitHub added to its platform that enables DevOps teams to track commits, builds and issues. That information is now also synchronized with a DevOps Insights tool from Octopus Deploy that surfaces metrics based on the DevOps Research and Assessment (DORA) metrics defined by Google.

    Other capabilities added to the integration include support for semantic versioning release tags within workflows, job summaries and a revamped user interface that makes GitHub easier to access from within Octopus Deploy.

    Sabikhi said that while GitHub Actions provides some deployment capabilities, the automation platform created by Octopus Deploy automates application release management across multiple clouds and on-premises IT environments. GitHub Actions is optimized for managing CI processes within the context of a Git-based workflow emanating from a cloud service managed by GitHub, he added.

    The integration with GitHub Actions makes it simpler to extend those Git-based workflows across multiple deployment platforms, noted Sabikhi.

    GitOps is, essentially, a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. GitHub views GitOps as a means of extending a code repository into the realm of DevOps workflows using the GitHub Actions platform.

    As organizations embrace GitOps, however, many are finding it advantageous to more loosely couple CI and CD platforms. Integrated CI/CD platforms have been around now for more than a decade, but few organizations have been able to truly automate the delivery of applications using those platforms. Platforms such as Octopus Deploy have been created from the ground up to specifically manage deployments of applications. In addition to GitHub Actions, Octopus Deploy also provides integrations with multiple other CI platforms to enable DevOps teams to mix and match CI platforms as they best see fit, said Sabikhi.

    It’s not clear how many DevOps teams are willing to acquire a separate CD platform, but as applications become more challenging to build and deploy in the cloud-native era many organizations are revisiting the DevOps processes they used to build and deploy monolithic applications. The challenge is many of them have spent years defining workflows based on legacy CI/CD platforms, so there is a lot of existing inertia that would need to be overcome when adopting a dedicated CD platform.

    It’s clear that CD is finally becoming more achievable using platforms that automate much of the process. Each DevOps team will need to decide how many staff they want to dedicate specifically to managing those CD platforms; the pace at which applications are being deployed should accelerate as application release management becomes more automated.

  • Opsera Brings DevOps Intelligence to GitHub Actions

    Opsera Brings DevOps Intelligence to GitHub Actions

    Opsera today announced it has extended its platform for collecting DevOps intelligence to include support for the GitHub Actions continuous integration/continuous delivery (CI/CD) platform.

    Opsera CEO Kumar Chivukula said as GitHub Actions is adopted more widely, there is a growing need to provide greater visibility into Git-based workflows in real-time. A GitHub Actions Insights module for the Opsera platform makes it possible to track key performance indicators (KPIs) across those workflows, he added.

    The goal is to make it simpler to make data-driven decisions about how best to optimize those workflows by identifying bottlenecks, noted Chivukula.

    The Opsera platform surfaces that intelligence by scanning all repositories and branches, including commit history, and generating alerts and notifications whenever KPI thresholds or compliance requirements are exceeded. DevOps teams can also use the platform to assess their overall DevOps maturity using a set of DevOps Research and Assessment (DORA) metrics defined by Google. Going forward, Opsera also plans to start surfacing metrics based on the Supply chain Levels for Software Artifacts (SLSA) framework for securing software supply chains also defined by Google.

    Platforms such as Opsera make it possible to apply analytics to DevOps workflows as they become more complex. The number of dependencies that exist between various application modules, for example, makes it exceedingly difficult for DevOps teams to manually identify the impact a delay in one project might have on any number of other downstream projects.

    In addition, many organizations are keen to discover what best practices should be adopted by other application development teams.

    Finally, many developers tend to use a repository as a dumping ground for all kinds of software artifacts, noted Chivukula. DevOps teams need an intelligence tool that makes it possible to identify which of those artifacts are the most essential to the business, he added. Otherwise, manually combing through a repository looking for artifacts becomes the DevOps equivalent of looking for a needle in a haystack, noted Chivukula.

    GitOps is essentially a more opinionated approach to DevOps that relies on an instance of the open source Git repository as the single source of truth about the environment rather than a set of application or server configuration files. GitHub views GitOps as a means of extending a code repository into the realm of DevOps workflows using the GitHub Actions platform. It’s not clear how much traction GitHub Actions is gaining at the expense of other CI/CD platforms, but for organizations that are relatively new to DevOps and already using GitHub as a code repository, it presents a path of least resistance.

    Regardless of why organizations adopt a DevOps intelligence platform, the need to optimize workflow across toolchains is becoming more pressing during an economic downturn. It’s becoming more clear that the cost of an application delivery delay directly impacts the level of revenue an organization generates in the age of digital business transformation.

  • Armory Extends Scope of Spinnaker CD Distribution

    Armory Extends Scope of Spinnaker CD Distribution

    Armory today updated both the self-hosted and managed editions of its distribution of the open source Spinnaker continuous delivery (CD) platform. The updates support concurrent pipelines and provide tighter integration with open source Terraform infrastructure-as-code (IaC) to better enforce policies.

    Previously, the two platforms were known as Armory Enterprise and Armory Enterprise Managed. They are now being rechristened; Armory Continuous Deployment Self-Hosted becomes Armory Continuous Deployment Managed in part to provide more differentiation from a CD cloud service the company rolled out last month that is not based on Spinnaker.

    Adam Frank, vice president of product for Armory, said other capabilities added to the platform include additional testing tools for contributions to the Spinnaker platform as well as enhanced plug-ins and remediation capabilities for Common Vulnerabilities and Exposures (CVEs) that might impact the Spinnaker platform.

    Despite launching a declarative CD-as-a-service platform that is not based on Spinnaker, Armory remains committed to supporting organizations that prefer to continue to rely on the open source platform, said Frank.

    The number of organizations that routinely make use of a dedicated CD platform is still relatively small. While organizations have been employing continuous integration (CI) within a CI/CD platform, making use of the CD element of those platforms has proven challenging. Each platform used to run applications has been unique, so automating delivery has been problematic. CI platforms, in some cases, have been extended using custom scripts to automate application delivery, but those efforts don’t typically scale across an extended enterprise. Many organizations that attempted to extend the open source Jenkins CI/CD platform, for example, are now looking to more loosely couple CI and CD processes to make DevOps workflows less brittle, noted Frank.

    Armory is making a case for a distinct CD platform at a time when more organizations are starting to build microservices-based applications on Kubernetes clusters that expose a standard set of application programming interfaces (APIs) regardless of what infrastructure they are deployed on. In many cases, those organizations now need to manage multiple pipelines in parallel as application environments become more complex rather than relying on a single pipeline, noted Frank.

    There’s no doubt that as the pace of application development continues to accelerate, the need to automate CD will become a more pressing issue. DevOps teams are releasing a larger number of smaller updates to applications and there’s also a need to be able to easily roll back those updates in case an unexpected issue is encountered, said Frank.

    It’s not clear yet how many organizations will be adopting dedicated CD platforms, but as application development continues to evolve many DevOps teams will, at the very least, be revisiting their existing processes. At the same time, there are also many organizations that are just beginning their DevOps journey. Most of those organizations are not committed to one CI/CD approach versus another.

    Regardless of approach, however, the expectation in the era of digital business transformation is organizations will be able to deliver software updates in a timely manner. The only way to achieve that goal, however, will be to have some type of CD capability that reliably operates at the scale required by organizations that need to operate like a true software company.

  • Continuous Delivery Advances Come at Cost of Testing

    Continuous Delivery Advances Come at Cost of Testing

    A survey of 820 application development professionals conducted by Applitools, a provider of an application testing platform, found well over a third of respondents (38%) working for organizations that now deploy daily changes to production environments.

    The challenge is that application testing is not able to keep pace with that rate of continuous deployment (CD). The survey found organizations are seeing test suites covering less than 50% of applications.

    Applitools COO Moshe Milman said a major reason test coverage is so low is that more than 40% of respondents said their continuous integration (CI) test suites can take more than an hour to run, which often resulted in tests either being postponed or possibly not run at all, he noted.

    Most organizations are also still relying on manual testing processes that can’t keep pace with the accelerated rate of application deployment and subsequent updates, added Milman. More than half of organizations (55%) automated less than half of their testing, according to the survey. More than two-thirds of respondents (67%) are embracing test automation to improve their test coverage, the survey found.

    In general, the percentage of organizations that are now employing CD processes to accelerate the pace at which applications are deployed is steadily increasing, said Milman. Manual testing processes, however, slow down the rate at which organizations deploy code. Many organizations routinely make trade-offs between application quality and a need to deploy code faster. Inevitably, there will be issues that can be traced back to decisions to not adequately test code prior to deployment, noted Milman.

    Overall, the survey found 90% of respondents building and deploying web applications, followed by 52% that were building and deploying mobile applications. Only 30% are building desktop applications. Testing of the applications, however, tends to vary widely. Nearly two-thirds of respondents (65%) said they tested applications on an end-to-end basis, with 55% testing integration followed by unit testing (53%) and application programming interface (API) testing (51%).

    However, only 26% tested application performance, followed by 13% that tested security and 12% that tested load, the survey found.

    Part of the issue, of course, is that it’s not always clear who is responsible for application testing. In theory, developers are accepting more responsibility for application testing as they take more responsibility for managing applications on an end-to-end basis. In practice, developers are often rushing to make application development deadlines. It’s not uncommon for developers to skip or limit testing in the name of productivity. Many of them have also embraced agile development methodologies that, at least theoretically, allow them to address any issues that might arise via the next application update.

    The issue that arises is that end users have become less tolerant of experimentation. If an application doesn’t initially work as expected, it’s exceedingly difficult to regain user confidence. Many will simply evaluate another similar application. The irony, of course, is that in the race to deliver code faster, application experience winds up being sacrificed because of the lack of time to properly test an application before deploying it.

  • CircleCI Integrates CI/CD Platform With GitLab

    CircleCI Integrates CI/CD Platform With GitLab

    CircleCI today announced it has integrated its continuous integration/continuous delivery (CI/CD) platform with a rival software-as-a-service (SaaS) offering from GitLab.

    DevOps teams can now, for example, trigger pipelines in CircleCI from GitLab forked merge requests in addition to merging requests and making commits for specific branches. Other capabilities include the ability to access testing capabilities on the CircleCI platform and integrate permissions to ensure security.

    CircleCI CEO Jim Rose said the company routinely integrates its CI/CD platform with other offerings because organizations typically have multiple teams using different version control platforms at different times. The goal is to give those teams access to capabilities and best practices regardless of which specific platform they are using.

    In general, Rose said organizations are trying to strike a balance between the standardization of DevOps platforms and the need to enable development teams to innovate by adding new tools. Standardization tends to create more opportunities to automate more tasks in ways that reduce costs. However, developers will eventually rebel against any effort to limit the choice of tools they use to improve productivity, noted Rose. Too many senior IT leaders are quick to assume that a plethora of tools is an indication of a problem rather than the result of ongoing experimentation, he added.

    In the wake of the global economic downturn, many organizations are also revisiting their existing DevOps workflows to try to increase overall efficiency by automating more tasks. Those organizations realize they can’t afford to continue throwing labor at manual DevOps tasks, Rose added.

    The challenge, of course, is that building and deploying modern software is becoming more complex. Organizations are embracing microservices to make applications more resilient as they realize how dependent they are on software. The issue is that as the number of microservices continues to expand, it becomes apparent that legacy manual processes will not scale, said Rose. As a result, the impetus to automate DevOps processes becomes that much greater, he added. Less clear is to what degree organizations that have already embraced DevOps platforms might be willing to swap out their current CI/CD platform to achieve that goal.

    In the meantime, more organizations are embracing DevOps to manage software development projects that drive a wide range of digital business transformation initiatives. The applications driving those processes typically need to be continuously updated as business requirements change. That becomes much easier to achieve when using processes optimized around continuous development and deployment.

    Regardless of which underlying CI/CD platform organizations choose, they should assume that, eventually, some level of integration between those platforms will be necessary. After all, in the event of an acquisition, for example, it’s not likely both companies will have standardized on the same DevOps platform. Given the amount of time required to migrate from one DevOps platform to another the amount of time required for interoperability is inevitably going to be measured in months if not years.

  • Survey Shows Increased Reliance on DORA Metrics

    Survey Shows Increased Reliance on DORA Metrics

    A new survey found just under a quarter (23%) of respondents are now tracking all four of the DevOps metrics defined by the DevOps Research and Assessment Team (DORA), with another 17% now tracking three.

    The State of Developer Experience survey polled 129 IT professionals that play a role in software development and was conducted by LeanIX, a provider of a platform for managing the building of enterprise applications.

    Dominick Rose, vice president of product management and strategy for LeanIX, said the ability to track DORA metrics such as deployment frequency (77%), failure rate (73%), lead time for changes (63%) and mean-time-to-recovery (MTTR) (55%) are leading indicators of DevOps maturity.

    DORA metrics, which are defined and maintained by a unit of Google, are being used most frequently to drive agile planning (69%) and optimize continuous integration/continuous delivery (CI/CD) platforms (58%), the survey found.

    Overall, the survey revealed just under half of the respondents (47%) said their organization had a high level of DevOps maturity, defined as having adopted three or more DevOps working methods. Those working methods are: Being flexible to changes in customer needs; having implemented a CI/CD platform; all engineers build, ship and own their own code; teams are organized around topologies and each team is free to choose its own technology stack.

    Of course, each individual organization will determine for itself what level of DevOps depth is required. For example, not every organization would see the need for teams to be organized around topologies or be free to choose its own technology stack. In fact, Rose said the survey made it clear that larger enterprise IT organizations tended to have a lower overall level of DevOps maturity. One reason for that is many larger organizations are still employing legacy processes to build and deploy software, noted Rose.

    Most developers are also further along in terms of embracing continuous integration (CI) than IT operations teams are in adopting continuous delivery (CD), added Rose. However, as the number of applications being developed using low-code and no-code tools continues to increase, it’s only a matter of time before application delivery needs to become more automated, he said. Achieving that goal will become easier as more artificial intelligence (AI) is incorporated into IT operations, Rose added.

    Nevertheless, the survey made it clear there is still a long way to go in terms of bridging the divide between DevOps teams and the rest of the business, with only 20% of respondents indicating that they use a value stream management (VSM) platform to track engineering efficiency to tie development activities to actual business results.

    A total of 71% of respondents, however, tracked open support tickets as a measure of customer value, followed by 66% that tracked monthly users and 45% that tracked feature adoption.

    It remains to be seen how DevOps will be further promulgated throughout organizations but as more organizations realize how dependent they are on software, it then becomes a question of how fully they embrace DevOps best practices as the pace at which applications are being built and deployed continues to accelerate.