# Continuous Delivery (CD) Continuous delivery is a software development practice that automates building, testing, configuration, and deployment while keeping changes ready for production release. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Introducing Consort: Test-driven development on a branching database DevFeed: [Introducing Consort: Test-driven development on a branching database]() Original publisher: [Read original article]() Author: Kevin Hartman Published: 2026-09-09T13:41:25Z Content type: article Language: en Sources: [Databricks]() Topics: [Test-driven development](), [Database](), [Integration testing](), [Software Engineering](), [Refactoring](), [Continuous Delivery (CD)](), [Pull Request](), [Reverse Engineering]() Tags: [code](), [continuous-delivery](), [database](), [development](), [integration](), [partners](), [platform](), [postgres](), [pull-request](), [refactoring](), [reverse-engineering](), [software](), [software-development](), [testing]() ### AI overview The article introduces Consort, a workflow for applying test-driven development to a branching database. It argues that copy-on-write branches of a real database can replace mocks, bring integration testing into the inner development loop, and let engineers run destructive tests in isolation. Versioned schema migrations can move with the dependent code, enabling what the article calls Data CD and helping catch production database problems during pull requests and merges. ### Source excerpt For 25 years I built software on the practices I grew up with: Kent Beck's TDD, Martin... ## Harness RT Agents Detect Resilience Risks and Generate Tests for CD Pipelines and Kubernetes Workloads DevFeed: [Harness RT Agents Detect Resilience Risks and Generate Tests for CD Pipelines and Kubernetes Workloads]() Original publisher: [Read original article]() Author: Uma Mukkara Published: 2026-08-24T00:00:00Z Content type: release Language: en Sources: [Harness Blog]() Topics: [Resilience](), [Testing](), [Continuous Delivery (CD)](), [Kubernetes](), [dashboards]() Tags: [agentic](), [agents](), [blog](), [chaos](), [configuration](), [continuous-delivery](), [dashboards](), [deployment](), [experiments](), [infrastructure](), [insights](), [kubernetes](), [load](), [pipelines](), [product](), [resilience](), [services](), [teams](), [testing](), [tests]() ### AI overview Harness announces an update to Resilience Testing called RT Agents. The agents analyze CD pipelines and Kubernetes workloads for resilience risks, recommend the testing needed to confirm those risks, and can generate and run chaos experiments or load tests and interpret the results. ### Source excerpt RT Agents detect resilience risk in your CD pipelines and Kubernetes workloads, then generate and run chaos experiments or load tests to confirm it. | Blog ## Continuous Delivery Excellence with Harness IDP DevFeed: [Continuous Delivery Excellence with Harness IDP]() Original publisher: [Read original article]() Author: Rashmi Hegde Published: 2026-08-21T00:00:00Z Content type: article Language: en Sources: [Harness Blog]() Topics: [Continuous Delivery (CD)](), [internal developer portal](), [CI/CD](), [Platform Engineering](), [Deployment](), [Automation](), [Orchestration](), [Provisioning]() Tags: [automation](), [ci-cd](), [continuous-delivery](), [deployment](), [developer-velocity](), [idp](), [internal-developer-portal](), [orchestration](), [platform-engineering](), [provisioning](), [self-service](), [tooling]() ### AI overview This article explains how Harness Internal Developer Portal can support continuous delivery through self-service workflows, standardized deployment pipelines, and unified service catalogs. It argues that delivery friction often comes from cognitive overhead, unclear prerequisites, fragmented permissions and configuration, and insufficiently discoverable workflows rather than a lack of pipeline capability. ### Source excerpt Achieve continuous delivery excellence using Harness Internal Developer Portal. Streamline deployments, boost velocity, and empower developers. Learn more. | Blog ## Software Delivery Platform: Key Features & How to Evaluate DevFeed: [Software Delivery Platform: Key Features & How to Evaluate]() Original publisher: [Read original article]() Author: Eric Minick Published: 2026-08-11T00:00:00Z Content type: article Language: en Sources: [Harness Blog]() Topics: [Software](), [CI/CD](), [Continuous Delivery (CD)](), [Continuous integration]() Tags: [audit](), [automation](), [blog](), [ci-cd](), [ci-cd-pipeline](), [governance](), [how-to](), [progressive-delivery](), [rollback](), [scalability](), [security](), [software-delivery](), [visibility]() ### AI overview This article explains how a software delivery platform differs from a standalone CI/CD tool. It describes a platform as an integrated system covering the full after-code lifecycle, including continuous integration, continuous delivery, security, governance, insights, coordination, and rollback, then outlines criteria for evaluating vendors. ### Source excerpt A software delivery platform isn't just a CI/CD tool. Get the must-have feature checklist and the demo questions to use when evaluating vendors. | Blog ## Native AI Agent Deployment in Harness Continuous Delivery DevFeed: [Native AI Agent Deployment in Harness Continuous Delivery]() Original publisher: [Read original article]() Author: Akshit Madan Published: 2026-07-21T00:00:00Z Content type: article Language: en Sources: [Harness Blog]() Topics: [AI Agent](), [Deployment](), [Continuous Delivery (CD)](), [Security](), [Software](), [agent observability]() Tags: [agentic](), [ai](), [ai-agent](), [audit-trail](), [continuous-delivery](), [deployment](), [harness](), [progressive-delivery](), [security]() ### AI overview This Harness article introduces agent deployment in Harness Continuous Delivery, with governed pipelines, native runtime support for platforms including Google's Agent Runtime and Amazon Bedrock AgentCore, progressive delivery, policy controls, and audit trails. It explains deployment as a critical stage of the agent development lifecycle and describes coordinating agents with backend services, database changes, and prompt or model configuration. ### Source excerpt Deploy AI agents with Harness Continuous Delivery using governed pipelines, native runtime support, progressive delivery, and built-in security. | Blog ## How To Set Up a Staging Environment on Heroku in 3 Easy Steps DevFeed: [How To Set Up a Staging Environment on Heroku in 3 Easy Steps]() Original publisher: [Read original article]() Author: Andy Smith Published: 2026-07-16T18:23:58Z Content type: tutorial Language: en Sources: [Heroku]() Topics: [Heroku](), [Deployment](), [Continuous Delivery (CD)](), [Testing](), [pull-requests](), [Git](), [GitHub]() Tags: [continuous-delivery](), [continuous-deployment](), [deployment](), [engineering](), [github](), [heroku](), [heroku-pipelines](), [how-to](), [pull-requests](), [testing]() ### AI overview A tutorial explains how to create a staging environment on Heroku by separating configuration and databases, grouping applications in Heroku Pipelines, and promoting tested compiled slugs to production. It also covers continuous delivery, disabling automatic deployment during setup, and optional Review Apps for pull requests. ### Source excerpt Moving fast should not mean breaking things for your users. While testing on localhost is a good start, you need a near identical replica of production to catch any bugs before your code goes live. That is where a staging environment comes in. Heroku pipelines handle the infrastructure layout for you, keeping your deployment workflow clean and automated. The post How To Set Up a Staging Environment on Heroku in 3 Easy Steps appeared first on Heroku. ## Agentic code workflows with Nick Tune DevFeed: [Agentic code workflows with Nick Tune]() Original publisher: [Read original article]() Author: Dr Milan Milanović Published: 2026-03-26T16:01:37Z Content type: article Language: en Sources: [Tech World With Milan Newsletter]() Topics: [agentic-coding](), [ai-coding](), [Claude Code](), [Code quality](), [code reviews](), [Test-driven development](), [Testing](), [Command-line interface](), [Domain-driven design (DDD)](), [migration](), [Requirements](), [Continuous Delivery (CD)]() Tags: [agentic](), [agentic-coding](), [agents](), [ai-coding](), [ai-tools](), [best-practices](), [claude-code](), [cli](), [code-quality](), [code-reviews](), [continuous-delivery](), [domain-driven-design](), [migration](), [requirements]() ### AI overview An interview with Nick Tune about advanced agentic coding workflows. It covers planning requirements, modeling development as a tested state machine, implementing features with Claude Code and guardrails, enforcing architecture rules deterministically, reviewing pull requests, applying TDD, and using custom tooling. ### Source excerpt Most engineers who talk about AI productivity talk in abstractions. ## Breaking the release monolith: How OutSystems platform engineering restored trust in delivery DevFeed: [Breaking the release monolith: How OutSystems platform engineering restored trust in delivery]() Original publisher: [Read original article]() Published: 2026-03-19T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Platform Engineering](), [Cloud Native Ecosystem](), [Continuous Delivery (CD)](), [Microservices](), [Kubernetes]() Tags: [chainguard-assemble](), [chainguard-containers](), [cloud-native](), [continuous-delivery](), [kubernetes](), [microservices](), [outsystems](), [outsystems-pegasus](), [platform-engineering](), [release]() ### AI overview The article describes how OutSystems transformed a slow, synchronized software release process through platform engineering. Its cloud-native OutSystems Developer Cloud used microservices and Kubernetes, but releases still followed an older release-train model. The company's journey included building the Pegasus CD platform and restoring trust in delivery. ### Source excerpt At Chainguard Assemble 2026, Outsystems shared how it transformed its release process through platform engineering. ## Heroku GitHub Enterprise Integration enters closed pilot with GitHub App-based connections DevFeed: [Heroku GitHub Enterprise Integration enters closed pilot with GitHub App-based connections]() Original publisher: [Read original article]() Author: Alberto Sigismondi Published: 2025-12-10T16:00:09Z Content type: release Language: en Sources: [Heroku]() Topics: [Heroku](), [CI/CD](), [Continuous Delivery (CD)](), [GitHub]() Tags: [continuous-delivery](), [continuous-integration](), [credentials](), [deployment](), [heroku](), [heroku-enterprise](), [heroku-pipelines](), [integration](), [news](), [security]() ### AI overview Heroku announces a closed pilot of its GitHub Enterprise Integration for Heroku Enterprise customers. The integration uses a dedicated GitHub App-based service identity instead of personal OAuth tokens to connect GitHub Enterprise Server or Cloud with Heroku deployment pipelines. ### Source excerpt We're excited to announce a significant enhancement to how Heroku Enterprise customers connect their deployment pipelines to GitHub Enterprise Server (GHES) and GitHub Enterprise Cloud (GHEC). The new Heroku GitHub Enterprise Integration is now available in a closed pilot, offering a more secure, robust, and permanent connection between your code repositories and your Heroku apps. [...] The post Heroku GitHub Enterprise Integration: Unlocking Full Continuous Delivery for Enterprise Customers appeared first on Heroku. ## Improved Browser Testing on Heroku with Chrome DevFeed: [Improved Browser Testing on Heroku with Chrome]() Original publisher: [Read original article]() Author: Mars Hall Published: 2024-04-09T22:00:00Z Content type: article Language: en Sources: [Heroku]() Topics: [Heroku](), [Browser Automation](), [Chrome](), [Testing](), [CI/CD](), [Continuous Delivery (CD)]() Tags: [automated](), [browser](), [buildpacks](), [chrome](), [ci](), [continuous-delivery](), [continuous-integration](), [developer-tools](), [engineering](), [heroku](), [security](), [testing](), [tests]() ### AI overview Heroku introduces the Chrome for Testing Heroku Buildpack, a community buildpack designed to improve installation reliability for automated browser testing in Heroku apps. It addresses Chrome and Chromedriver version mismatches by keeping their versions aligned for testing environments. ### Source excerpt For developers and businesses offering a web-based product, automated browser testing is a critical tool to ensure continuous delivery of a reliable service. Developers write browser tests by scripting actions against a real browser, simulating real usage by navigating, selecting, and making assertions about web pages and their document elements. In this post, we introduce [...] The post Improved Browser Testing on Heroku with Chrome appeared first on Heroku. ## How Continuous Delivery Improves Mobile Developer Productivity DevFeed: [How Continuous Delivery Improves Mobile Developer Productivity]() Original publisher: [Read original article]() Author: Ben Published: 2023-07-07T09:58:55Z Content type: article Language: en Sources: [Novoda]() Topics: [Mobile](), [Continuous Delivery (CD)](), [code productivity](), [Release Management](), [Testing]() Tags: [automated](), [ci-cd](), [continuous-delivery](), [developer-productivity](), [engineering](), [mobile](), [mobile-engineering](), [release-cadence]() ### AI overview This article explains how continuous delivery can improve productivity for mobile development teams. It discusses adapting CI/CD practices to mobile constraints, shortening feedback cycles, automating testing, finding bugs faster, and using weekly or fortnightly release cadences to support continual iteration. ### Source excerpt When properly implemented, continuous delivery practices and processes allow your mobile teams to build and deploy products at a much faster rate by improving developer productivity. We explore how. The post How Continuous Delivery Improves Mobile Developer Productivity appeared first on Novoda. ## Adopting Continuous Delivery: More a culture change than automation of processes DevFeed: [Adopting Continuous Delivery: More a culture change than automation of processes]() Original publisher: [Read original article]() Author: tobi@techunicorn.builders (Tobias Mende) Published: 2021-12-04T12:07:00Z Content type: article Language: en Sources: [Tobias Mende]() Topics: [Continuous Delivery (CD)](), [Automation](), [Software]() Tags: [automation](), [burnout](), [continuous-delivery](), [continuous-deployment-software-development-developer-productivity-engineering-excellence-organiz](), [faster](), [ownership]() ### AI overview The article argues that adopting continuous delivery requires a culture and process change, not merely automating manual deployment activities. It recommends understanding existing delivery processes, responsibilities, risks, and safety mechanisms before simplifying or automating them. ### Source excerpt Adopting Continuous Delivery: More a culture change than automation of processes Continuous delivery, the process of automatically delivering changes of a system without human interaction, is one of the most beneficial practices that software teams can adopt. In Accelerate, the authors Nicole Forsgren, Jez Humble and Gene Kim, discovered a strong link between using continuous delivery and organisational performance: Teams that continuously deliver their changes have a stronger sense of ownership, get faster feedback and need to rework their code less. Furthermore, deployments are less stressful and the risk of burnout is reduced. ## Zero to One and Beyond: HackerEarth's journey to Continuous Delivery DevFeed: [Zero to One and Beyond: HackerEarth's journey to Continuous Delivery]() Original publisher: [Read original article]() Published: 2021-08-01T00:00:00Z Content type: article Language: en Sources: [HackerEarth]() Topics: [CI/CD](), [Continuous Delivery (CD)](), [Continuous Deployment (CD)](), [ci](), [Deployment](), [Agile]() Tags: [agile](), [ci](), [ci-cd](), [code](), [continuous-delivery](), [continuous-deployment](), [deployment]() ### AI overview HackerEarth describes its journey from frequent but failure-prone deployments toward continuous delivery and continuous deployment. The article explains how continuous integration, fast feedback near the point of failure, deployable software, and on-demand push-button deployments can improve release cadence and reduce costly production issues. ### Source excerpt "Hey the deployment is broken again. Can you push this change again" "Hey, I merged my changes were merged in the morning. I still don't see them in production yet" "Argh, the static files are not updated. We have to run deployment again" These voices hollared across the hallway and this was followed by a huddle to sort things out. These voices soon grew louder and then we realised: Our Deployment is broken. Epilogue At HackerEarth, we have always been good at embracing bleeding edge technologies. We have always taken pride at doing what is right and acknowledge when something needs a fix. A faster delivery cadence and a quicker release cycle are very important for a startup of our scale. Our deployment related problems threatened our fundament need - "Pace" This prompted us to not just fix what was broken but to introduce a new paradigm to deployment - Continuous Deployment. The key tenets of following agile to push consistent smaller pieces of software frequently to customers and get Feedback. As any growing team, we were at one point struggling with - higher deployment failures or critical issues leaking to production. What followed was our path to redemption Circa 2019, HackerEarth was already doing frequent deployments. We had a process to collect, merge, tag and release code into production. But, this was not enough. As it must be obvious now, our feedback cycle was not close to the point of failure. The Integration happened closer to production and any failure is now expensive to fix. This is where our journey up the CI-CD ladder begun. You're doing continuous delivery when: Your software is deployable throughout its lifecycle Your team prioritises keeping the software deployable over working on new features Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them You can perform push-button deployments of any version of the software to any environment on demand" -- Martin Fowler When it all ## Tips and Tricks for GitHub Actions DevFeed: [Tips and Tricks for GitHub Actions]() Original publisher: [Read original article]() Author: Harsh Shandilya Published: 2021-01-02T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Harsh Shandilya]() Topics: [GitHub Actions](), [CI/CD](), [GitHub](), [ci](), [Continuous Delivery (CD)](), [Pull Request]() Tags: [ci](), [ci-cd](), [deployment](), [github](), [github-actions](), [jobs](), [pull-request](), [schedules](), [tips](), [tips-and-tricks](), [workflows]() ### AI overview A practical guide to GitHub Actions covering scheduled workflows, automation triggered by repository events, commit-message conditions, pull-request automation, and workflow security. Examples include synchronizing public suffix data and checking Rust compiler issues. ### Source excerpt GitHub Actions is a power CI/CD platform that can do a lot more than your traditional CI systems. Here's some tips to get you started with exploring its true potential. ## Interview for BrowserStack's Breakpoint 2020 Conference DevFeed: [Interview for BrowserStack's Breakpoint 2020 Conference]() Original publisher: [Read original article]() Author: Matthias Endler Published: 2020-07-03T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [Testing](), [Test automation](), [Continuous Delivery (CD)](), [Cucumber](), [Open Source]() Tags: [bdd](), [conference](), [continuous-delivery](), [engineering-culture](), [interview](), [open-source](), [qa](), [release-engineering](), [test-automation](), [testing]() ### AI overview This article announces Benjamin Bischoff's BrowserStack interview and talk for the virtual Breakpoint 2020 testing summit. It introduces his work in test automation at trivago and describes the company's technical and procedural changes toward more efficient continuous delivery. ### Source excerpt After 15 years as a game/application developer and trainer, Benjamin decided to make test automation his career. He's currently a Test Automation Engineer in trivago's core QA team. Benj... ## Keycloak Releases and Versioning DevFeed: [Keycloak Releases and Versioning]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2019-04-24T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [releases](), [Continuous Delivery (CD)](), [version](), [deprecated](), [migration](), [API](), [Keycloak](), [Vulnerabilities]() Tags: [continuous-delivery](), [deprecated](), [idm](), [kerberos](), [keycloak](), [ldap](), [migration](), [migration-guide](), [openid-connect](), [preview](), [release](), [release-cadence](), [releases](), [saml](), [security-vulnerabilities](), [sso](), [versioning]() ### AI overview Keycloak describes changes to its release cadence and versioning to support continuous delivery. Feature releases will occur roughly four times a year and increment the major version, while individual features may be marked as preview. The project also plans more frequent micro releases focused on critical bugs and security vulnerabilities. ### Source excerpt We are aiming to achieve a continuous delivery model with Keycloak. By that we mean it should be seamless to upgrade between Keycloak releases and to keep up to date with the latest release. This requires no breaking changes, but rather deprecating old APIs allowing time to migrate to new APIs. Traditional semantic versioning does not fit very well with this model. By following the mantra of continuous delivery we would forever be stuck on a major version and only update the minor version, and you could argue whether or not it would be correct to update the major version when an API that has been deprecated for a long period of time is removed. With this in mind, we have made some slight changes to our release cadence and versioning schema. For now, we will have a new feature release roughly 4 times each year. Each release will bump the major version number. That doesn't mean there are breaking changes, but until we perfect our continuous delivery model there may be some, so always refer to the migration guide prior to upgrading! We have also decided to drop the Final suffix from releases. That is simply because it is not needed as we have not done any beta or release candidates for a long time. In the spirit of continuous delivery, we will have individual features marked as preview rather than whole releases. As a final note, with the reduced release cadence we are planning to do more micro releases. This will be focused on critical bugs and security vulnerabilities. However, we may accept contributions to less critical bugs given the fix is well tested and has low risk of regressions. ## Control your release DevFeed: [Control your release]() Original publisher: [Read original article]() Published: 2017-12-07T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [configuration](), [Deployment](), [Continuous Delivery (CD)](), [Code review](), [Automation](), [Containers]() Tags: [automation](), [code-review](), [configuration](), [containers](), [continuous-delivery](), [deployment](), [release-notes](), [repository](), [server]() ### AI overview This article recommends maintaining an up-to-date RELEASE_CHECKLIST.md file in the code repository and reviewing it with code changes. The checklist records manual steps required before, during, and after a release while teams work toward automating deployment and continuous delivery. ### Source excerpt Imagine the situation when you've just released something on production and deployment went fine. You've just sent release notes and went out to grab a coffee. Once you are back you see an email with information that feature team have been working on for past 3 sprints doesn't work at all. Turns out you forgot to change something in production server configuration. In this post, I'm going to present the simplest idea which will help you to avoid this kind of issues. Read more ## Target open-sources Winnaker to audit Spinnaker deployments DevFeed: [Target open-sources Winnaker to audit Spinnaker deployments]() Original publisher: [Read original article]() Author: Target Brands, Inc Published: 2017-02-13T06:00:00Z Content type: release Language: en Sources: [Target]() Topics: [Cloud](), [Tool](), [Continuous Delivery (CD)](), [Automation](), [Open Source](), [Deployment Strategies](), [Monitoring](), [Kubernetes]() Tags: [api](), [audit](), [automation](), [cloud](), [deployment](), [deployment-strategies](), [health-checks](), [identity-management](), [infrastructure](), [kubernetes](), [monitoring](), [open-source](), [platform](), [spinnaker](), [winnaker]() ### AI overview Target announces Winnaker, an open-source tool for auditing Spinnaker deployments from an end-user perspective. The article explains how Winnaker automates whole-system deployment testing and helps identify connectivity, API rate-limit, and infrastructure-configuration problems. ### Source excerpt Win the cloud with Winnaker! I am happy to announce that we, at Target, decided to open source a tool called Winnaker. This tool will allow the user to audit Spinnaker from an end user point of view. But first what is Spinnaker? The first time I heard the word Spinnaker, my reaction was, "wait, what does that even mean in English?" Shortly after, I found myself implementing a demo of Spinnaker as a potential replacement for our internal cloud deployment tool. Spinnaker is a cloud agnostic continuous delivery tool, which means we can push our code to any cloud provider we like. In fact, Spinnaker takes agnosticism to the next level by introducing three abstractions. Load balancers Server groups Security groups By enforcing this level of simplicity, it allows the implementation of deployment strategies such as Highlander, Red/Black on a vast different type of infrastructure (VM, Container, Kubernetes, public cloud, private cloud) with a high level of confidence and an incredible level of ease of use for the app developers. Spinnaker also roots for the immutable infrastructure design pattern. Baking your image once and deploying the image everywhere is another bold move that differentiates Spinnaker from the other tools. Why Winnaker ? Short answer is because of automation! Test the functionality of the CD system as a whole. Spinnaker has different components (CloudDriver, Rosco, Deck,...). Each of these components have their own unit tests and health checks that can be monitored. We learned the hard way that relying only on component health checks is not effective enough to ensure developers won't face any error when they deploy their apps. A few things can go wrong when off monitoring radar: Connectivity between the separate components Maxing out cloud provider API rate limit Base infrastructure configurations (subnet address space, identity management roles) So we decided to audit Spinnaker and cloud's whole functionality with a sample app. If baking and deploying our ## Continuous Delivery - Automating the Release Process DevFeed: [Continuous Delivery - Automating the Release Process]() Original publisher: [Read original article]() Author: umer Published: 2016-06-18T00:00:00Z Content type: article Language: en Sources: [Code Ahoy - Articles]() Topics: [Continuous Delivery (CD)](), [Continuous integration](), [Software Engineering](), [DevOps]() Tags: [automated](), [ci](), [configuration](), [continuous-delivery](), [release](), [tests]() ### AI overview The article explains how manual release processes can be slow, error-prone, and stressful, then introduces Continuous Delivery as an approach for automating releases. It describes production-like environments, extensive automated testing, fast developer feedback, and Continuous Integration as a prerequisite. ### Source excerpt For many software developers, release days are stressful events. There's always some risk that things might go wrong in the process or that a bug would surface in production. At my previous company, we had a manual release process that was very human intensive; hence, error prone. On release days, DevOps would load binaries on a staging environment and perform user acceptance tests (UAT) manually. If the tests were successful, the software was copied to production servers and verified with smoke tests and occasionally, a trimmed down version of the UAT was run again. Here are the common problems we faced: 2 out 3 times when we had to roll back a release because of an issue, it was due to a configuration mismatch between staging and production environments. The release process was slow and it took a long time to put new features in the hands of our users. It wasn't uncommon for the release process to take days or sometimes even weeks. The slow release process and the manual UAT had another side-effect: the developers didn't get timely feedback. By the time feedback arrived, they were often in the middle of another feature. This incurred additional overhead because their memories were no longer fresh and on rare occasions, the error got re-introduced due to mix-up between branches. In short, manual and ad-hoc release processes are suboptimal and the release day is fraught with stress. In our case, it was tolerable until releases became more frequent and the team grew. To improve and automate the release process, there's a software engineering approach know as Continuous Delivery (CD). Continuous delivery makes it possible to release new features quickly and reliably. It provides fast feedback to developers. The software is built in a way where it can be automatically and safely released to production at any time. This is ensured by delivering every change to a production-like environment and running extensive automated tests on it. According to Martin Fowler, you are ## Minimum Viable Product - Lessons for Software Teams DevFeed: [Minimum Viable Product - Lessons for Software Teams]() Original publisher: [Read original article]() Author: umer Published: 2016-05-07T00:00:00Z Content type: opinion Language: en Sources: [Code Ahoy - Articles]() Topics: [Development](), [Continuous Delivery (CD)](), [Testing]() Tags: [article](), [continuous-delivery](), [developers](), [development](), [testing]() ### AI overview The article explains minimum viable product (MVP) as a way for software teams to test customer demand and assumptions with limited effort. It uses Zappos as an example and distinguishes MVP from continuous delivery and incremental development. ### Source excerpt The concept of the minimum viable product or the MVP was popularized by Eric Reis in his book The Lean Startup. He defines it as: The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. Startups fail for many reasons but one of the biggest reasons is that they build products that their customers do not want. By that time, it's too late. They have already spent months or even years of their lives building a great product - a grand vision - that the market isn't, unfortunately, willing to purchase. MVP is a strategy to avoid exactly that scenario: building something that the customers do not want. Eric cites the story of Zappos. They didn't start out with a grand vision of building a cool website, distribution and call centers. Nope. Zappos started by testing a simple hypothesis: are customers willing to buy shoes online? They went to local shoe store, took pictures of each of their products and put them online. If anyone bought shoes from them [at this early stage], they planned to go to the store, buy the shoes and mail them to the customer. There was no big business behind it; there was a website and a hope that they'll get so many orders that it will get annoying to do all the purchasing and shipping manually. It was all to test their big idea. MVP is a great way to test the actual usage and assumptions as opposed to conventional market research that includes researching online, surveys etc. which often provide misleading results. Software teams can learn a lot from MVP and apply it to build products that meet their client needs. When I first heard of MVP, I thought of it as a rebranding of 'Continuous Delivery (CD)' which, along with the practices of incremental and iterative development, has been around for a long time. But there is a huge difference and it lies in how software developers understand and perceive these concepts. This article captures ## Continuous Delivery with GitHub, CircleCI, Docker and AWS Elastic Beanstalk DevFeed: [Continuous Delivery with GitHub, CircleCI, Docker and AWS Elastic Beanstalk]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2015-09-29T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [Continuous Delivery (CD)](), [CI/CD](), [Docker](), [CircleCI](), [GitHub](), [Docker Hub](), [Deployment](), [Amazon Web Services](), [Environment Variables]() Tags: [aws](), [circleci](), [continuous-delivery](), [deployment](), [docker](), [docker-hub](), [environment-variables](), [github]() ### AI overview This tutorial explains a continuous delivery setup for a Go service using GitHub, CircleCI, Docker, Docker Hub, and Amazon Elastic Beanstalk. Commits pushed to the site repository are built into Docker images, tagged with the CircleCI build number, pushed to Docker Hub, and deployed to production so deployed commits can be traced through the image and build tags. ### Source excerpt This is just a quick overview of how I did it in antibody's homepage. ## Notes on Continuous Delivery Deployment Pipelines DevFeed: [Notes on Continuous Delivery Deployment Pipelines]() Original publisher: [Read original article]() Author: Graham King Published: 2015-01-25T04:44:31Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [Continuous Delivery (CD)](), [CI/CD](), [Automation](), [DevOps](), [Database Migration](), [Ansible](), [Puppet]() Tags: [ansible](), [automation](), [book](), [continuous-delivery](), [database-migration](), [devops](), [pipeline](), [puppet](), [software]() ### AI overview Notes on Continuous Delivery describe deployment pipelines, automation, and DevOps collaboration. They cover commit tests, automated acceptance tests, artifact storage, environment provisioning, deployment, and database migration practices. ### Source excerpt Streamline your software delivery process with automation and collaboration. ## Dark Launching and Feature Toggles DevFeed: [Dark Launching and Feature Toggles]() Original publisher: [Read original article]() Author: mick Published: 2013-06-20T11:56:20Z Content type: article Language: en Sources: [Finn.no]() Topics: [Deployment](), [DevOps](), [CI/CD](), [Continuous Delivery (CD)](), [Development]() Tags: [continuous-delivery](), [deployment](), [devops](), [incremental](), [modular](), [operations](), [production]() ### AI overview The article distinguishes dark launching from feature toggles. It describes dark launching as silently deploying a component, allowing production validation, rollback, and graceful failure, while feature toggles are associated with selective activation, A/B testing, and analytics. It argues that dark launching can support incremental development, continuous delivery, and simpler cleanup. ### Source excerpt Make sure to distinguish between these two. They are not the same thing, and it's a lot quicker to just Dark Launch. In addition Dark Launching promotes incremental development, continuous delivery, and modular design. Feature Toggles need not, and can possibly be counter-productive. Dark Launching is an operation to silently and freely deploy something. Giving you time to ensure everything operates as expected in production and the freedom to switch back and forth while bugfixing. A Dark Launch's goal is often about being completely invisible to the end-user. It also isolates the context of the deployment to the component itself. Feature Toggling, in contrast, is often the ability to A/B test new products in production. Feature Toggling is typically accompanied with measurements and analytics, eg NetInsight/Google-Analytics. Feature Toggles may also extend to situations when the activation switch of a dark launch can only happen in a consumer codebase, or when only some percentage of executions will use the dark launched code. Given that one constraint of any decent enterprise platform is that all components must fail gracefully Dark Launching is the easiest solution, and a golden opportunity to ensure your new code fails gracefully. Turn the new module on, and it's dark launched and in use, any problems turn it off again. You also shouldn't have to worry about only running some percentage of executions against the new code, let it all go to the new component, if the load is too much the excessive load should also fail-gracefully and fall back to the old system. Dark Launching is the simple approach as it requires no feature toggling framework, or custom key-value store of options. It is a DevOps goal that remains best isolated to the context of DevOps - in a sense the 'toggling' happens through operations and not through code. When everything is finished it is also the easier approach to clean up. Dealing with and cleaning up old code takes up a lot of our time an