# Continuous Deployment (CD) Continuous deployment is a DevOps practice that automatically deploys each successful code change to production without manual intervention. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Trust Factory DevFeed: [Trust Factory]() Original publisher: [Read original article]() Author: Kent Beck Published: 2026-06-02T13:33:57Z Content type: opinion Language: en Sources: [Software Design: Tidy First?]() Topics: [trust](), [Code](), [Testing](), [CI/CD](), [Continuous Deployment (CD)](), [observability](), [Refactoring]() Tags: [code](), [continuous-deployment](), [continuous-integration](), [observability](), [refactoring](), [testing](), [trust]() ### AI overview This commentary argues that software development practices can function as a "trust factory." It connects programmer testing, pairing, continuous integration, weekly planning, customer involvement, continuous deployment, refactoring, and observability with building trust among developers, customers, and teams. ### Source excerpt "We're accumulating code faster than we are accumulating trust." Sometimes a phrase just hits. ## App Hosting adds support for Turborepo DevFeed: [App Hosting adds support for Turborepo]() Original publisher: [Read original article]() Author: Julia Reid Published: 2026-01-08T00:00:00Z Content type: release Language: en Sources: [Firebase Blog]() Topics: [Continuous Deployment (CD)](), [CI/CD](), [JavaScript](), [TypeScript](), [Next.js]() Tags: [app-hosting](), [continuous-deployment](), [dependencies](), [deployment](), [firebase](), [javascript](), [monorepo](), [next-js](), [parallel](), [typescript](), [web]() ### AI overview Firebase App Hosting now supports Turborepo for JavaScript and TypeScript monorepos. The article explains how Turborepo uses task configuration, dependency graphs, and parallel execution to support reliable and efficient builds and deployments. ### Source excerpt Efficient builds in App Hosting's continuous deployment pipeline, even for large and complex monorepos. ## Why Threat Modeling Is Now Even More Critical for AI-Native Applications DevFeed: [Why Threat Modeling Is Now Even More Critical for AI-Native Applications]() Original publisher: [Read original article]() Author: Snyk Team Published: 2025-11-20T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Security](), [ai security](), [Securing AI](), [Artificial Intelligence](), [Large Language Model](), [Continuous Deployment (CD)](), [Adversarial attacks]() Tags: [ai](), [ai-security](), [architecture](), [architectures](), [attacks](), [blog](), [continuous-deployment](), [engineering](), [executive](), [interest](), [language-models](), [large-language-models](), [security]() ### AI overview AI-native applications require continuous, adaptive threat modeling because their large language models, autonomous agents, evolving data flows, and runtime-integrated tools create dynamic and unpredictable security risks. The article explains why traditional manual, static, point-in-time assessments become stale and fail to scale, and highlights new attack surfaces such as data poisoning, model inversion, and adversarial attacks. ### Source excerpt AI-native applications demand a security approach as dynamic as they are. Traditional threat modeling is no longer enough. Discover the shift to continuous, adaptive threat modeling for AI security. ## Combine the Codefresh GitOps Cloud with your existing Argo CD instance DevFeed: [Combine the Codefresh GitOps Cloud with your existing Argo CD instance]() Original publisher: [Read original article]() Author: Kostis Kapelonis Published: 2025-04-30T08:16:16Z Content type: article Language: en Sources: [Codefresh]() Topics: [argo-cd](), [GitOps](), [Kubernetes](), [Continuous Deployment (CD)](), [Deployment](), [Git]() Tags: [argo](), [argo-cd](), [argocd](), [codefresh](), [continuous-deployment](), [declarative](), [deployment](), [git](), [gitops](), [kubernetes](), [product-and-tools](), [pull-request]() ### AI overview This article explains Argo CD as a Kubernetes-native continuous deployment tool and describes how Codefresh GitOps Cloud can work with an existing Argo CD instance. It covers GitOps workflows, application promotion across clusters, declarative configuration, approvals, and deployment synchronization. ### Source excerpt We recently announced the new Codefresh GitOps Cloud, the easiest way to promote changes across Argo CD applications-even across different clusters. With Codefresh GitOps Cloud, you can model your own promotion flow with a graphical editor (although YAML is still available). You define exactly how an application reaches production, including all the requirements and approval [...] The post Combine the Codefresh GitOps Cloud with your existing Argo CD instance appeared first on Codefresh. ## Our Tech Journey Update & Planning DevFeed: [Our Tech Journey Update & Planning]() Original publisher: [Read original article]() Author: Denis Čahuk Published: 2025-04-02T09:36:57Z Content type: article Language: en Sources: [Crafting Tech Teams]() Topics: [AI Agent](), [Artificial Intelligence](), [Continuous Deployment (CD)](), [Test-driven development](), [Code review]() Tags: [ai](), [ai-agent](), [code-review](), [continuous-deployment](), [tdd](), [tech](), [update](), [video]() ### AI overview The article outlines a 10-week live content plan covering AI assistance for tech businesses, AI agent setups, development workflows, testing, deployment, code review, and the economics of AI in product engineering. It also provides streaming platforms and scheduling information. ### Source excerpt A recording from Denis Čahuk's live video ## Scaling Technology with Architectural Principles DevFeed: [Scaling Technology with Architectural Principles]() Original publisher: [Read original article]() Author: Shane Gibb Published: 2025-01-08T01:18:36Z Content type: article Language: en Sources: [REA Group]() Topics: [scaling](), [Software Engineering](), [Development](), [Continuous Deployment (CD)](), [maintenance](), [Design system](), [CI/CD]() Tags: [code](), [continuous-deployment](), [continuous-integration](), [design-system](), [engineering](), [maintenance](), [scaling](), [tech]() ### AI overview REA Group describes how architectural principles developed through 25 years of growth guide its software engineering practices, including decision-making, system resilience, team agility, platform reuse, and continuous deployment. ### Source excerpt REA Group, a global company with 1,000+ digital product builders, developed architectural principles from 25 years of growth. ## From Code to Customer - How Continuous Deployment can Accelerate Your Software Development Cycle DevFeed: [From Code to Customer - How Continuous Deployment can Accelerate Your Software Development Cycle]() Original publisher: [Read original article]() Author: tobi@techunicorn.builders (Tobias Mende) Published: 2024-10-17T00:00:00Z Content type: article Language: en Sources: [Tobias Mende]() Topics: [Continuous Deployment (CD)](), [CI/CD](), [Infrastructure as code](), [Testing](), [Monitoring](), [Software Engineering]() Tags: [automated](), [collaboration](), [communication](), [continuous-deployment](), [infrastructure-as-code](), [monitoring](), [pipelines](), [testing](), [trust]() ### AI overview This talk explains how continuous deployment can streamline software delivery through infrastructure as code, automated testing, monitoring, and efficient deployment pipelines. It also discusses organizational changes such as collaboration, communication, and trust, using an example of implementation across 15 teams. ### Source excerpt Many organizations struggle with streamlining the software delivery process, resulting in slower delivery, lower quality, and decreased customer satisfaction. They also face challenges in establishing efficient CD pipelines and implementing cultural changes necessary for successful CD implementation. ## End-to-end tests retry strategies DevFeed: [End-to-end tests retry strategies]() Original publisher: [Read original article]() Author: Giuseppe Donati Web Test Automation Engineer Not a stereotypical Italian guy; Except Published: 2023-09-27T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [Testing](), [Test automation](), [GitHub Actions](), [CI/CD](), [Continuous Deployment (CD)](), [Front end](), [web applications]() Tags: [continuous-deployment](), [core](), [feature](), [frontend](), [github-actions](), [pull-requests](), [quality-assurance](), [test-automation](), [tests]() ### AI overview This article describes how trivago's frontend QA team uses different end-to-end test retry strategies in GitHub Actions. It explains unconditional retries for core tests, filtered retries for specific failure causes in extended tests, and manual retries for a subset of scenarios, balancing stable results, pull-request confidence, and feedback speed. ### Source excerpt Why should you retry all tests on failure? Why not? This article will not go into details, listing pros and cons of each approach. There are already enough ## 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 ## Continuous Deployment for AWS Glue DevFeed: [Continuous Deployment for AWS Glue]() Original publisher: [Read original article]() Author: Mohammed Published: 2020-10-15T15:51:25Z Content type: tutorial Language: en Sources: [Brave New Geek]() Topics: [AWS Glue](), [Continuous Deployment (CD)](), [GitHub Actions](), [Jupyter Notebook](), [Amazon S3]() Tags: [analytics](), [analytics-pipeline](), [aws](), [aws-glue](), [ci-cd](), [continuous-delivery](), [continuous-deployment](), [etl](), [github](), [github-actions](), [jupyter](), [jupyter-notebook](), [s3](), [serverless]() ### AI overview A tutorial for automating continuous deployment of AWS Glue ETL jobs. It uses GitHub Actions to generate a Python script from a Jupyter notebook, copy it to Amazon S3, and update the Glue job to use the new script. ### Source excerpt AWS Glue is a managed service for building ETL (Extract-Transform-Load) jobs. It's a useful tool for implementing analytics pipelines in AWS without having to manage server infrastructure. Jobs are implemented using Apache Spark and, with the help of Development Endpoints, can be built using Jupyter notebooks. This makes it reasonably easy to write ETL processes in an interactive, iterative fashion. Once finished, the Jupyter notebook is converted into a Python script, uploaded to S3, and then run as a Glue job. ## How I Built and Manage This Blog with Hugo, Markdown, Docker, and Automation DevFeed: [How I Built and Manage This Blog with Hugo, Markdown, Docker, and Automation]() Original publisher: [Read original article]() Published: 2020-02-14T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [Hugo](), [Markdown](), [Docker](), [Automation](), [Continuous Deployment (CD)]() Tags: [automation](), [continuous-deployment](), [docker](), [hugo](), [markdown]() ### AI overview The author describes how their blog evolved over three years, covering Hugo, Markdown and Asciidoc, theme customization, Docker-based local development, scripts, and continuous deployment possibilities. ### Source excerpt In this post, I'd like to show you how I've started with writing this blog. How the process evolved during 3 years of writing. How I've finally managed to set up everything in a way that works for me now. If you don't blog yet this might help you out with technical details on how you can start easily. If you already have a blog maybe you'll be able to pick up some ideas. Read more ## Tests that sometimes fail - flaky test tips DevFeed: [Tests that sometimes fail - flaky test tips]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2019-05-28T06:54:25Z Content type: article Language: en Sources: [Sam Saffron]() Topics: [Development](), [debug](), [CI/CD](), [Continuous Deployment (CD)]() Tags: [blog](), [c-sharp](), [continuous-deployment](), [debug](), [development](), [flaky](), [infection](), [net](), [pipeline](), [rails](), [ruby](), [saffron](), [sam](), [sql](), [tests](), [tips](), [weblog]() ### AI overview An article about flaky tests in mature projects, explaining how they can consume debugging time, disrupt continuous deployment, and sometimes reveal underlying application flaws. It describes Discourse's practices for identifying and mitigating them. ### Source excerpt The boy who cried wolf695x564 286 KB A liar will not be believed, even when he speaks the truth. : Aesop Once you have a project that is a few years old with a large test suite an ugly pattern emerges. Some tests that used to always work, start "sometimes" working. This starts slowly, "oh that test, yeah it sometimes fails, kick the build off again". If left unmitigated it can very quickly snowball and paralyze an entire test suite. Most developers know about this problem and call these tests "non deterministic tests", "flaky tests","random tests", "erratic tests", "brittle tests", "flickering tests" or even "heisentests". Naming is hard, it seems that this toxic pattern does not have a well established unique and standard name. Over the years at Discourse we have called this many things, for the purpose of this article I will call them flaky tests, it seems to be the most commonly adopted name. Much has been written about why flaky tests are a problem. Martin Fowler back in 2011 wrote: Non-deterministic tests have two problems, firstly they are useless, secondly they are a virulent infection that can completely ruin your entire test suite. To this I would like to add that flaky tests are an incredible cost to businesses. They are very expensive to repair often requiring hours or even days to debug and they jam the continuous deployment pipeline making shipping features slower. I would like to disagree a bit with Martin. Sometimes I find flaky tests are useful at finding underlying flaws in our application. In some cases when fixing a flaky test, the fix is in the app, not in the test. In this article I would like to talk about patterns we observed at Discourse and mitigation strategies we have adopted. Patterns that have emerged at Discourse A few months back we introduced a game. We created a topic on our development Discourse instance. Each time the test suite failed due to a flaky test we would assign the topic to the developer who originally wrote the test. Onc ## Year in review 2018 DevFeed: [Year in review 2018]() Original publisher: [Read original article]() Author: info@jeroenmols.com (Jeroen Mols) Published: 2019-01-01T00:00:00Z Content type: opinion Language: en Sources: [Jeroen Mols]() Topics: [Kotlin](), [Android](), [Continuous Deployment (CD)](), [Pluralsight](), [Mastodon]() Tags: [android](), [blogs](), [continuous-deployment](), [kotlin](), [mastodon](), [pluralsight](), [review](), [year-in-review]() ### AI overview A personal review of 2018 covering family life, building and moving into a house, professional challenges, community activities, conference talks, blog writing, Kotlin use, and plans for the following year. ### Source excerpt Sitting in our own couch, in our own house, kids safely asleep upstairs,... The road here was brutal, but the result is extraordinary. The past year was (hopefully) the busiest year of my entire life. ## Continuous Deployment: Hugo + Travis CI -\> GitHub Pages DevFeed: [Continuous Deployment: Hugo + Travis CI -\> GitHub Pages]() Original publisher: [Read original article]() Author: Chris Hager Published: 2017-04-25T00:00:00Z Content type: tutorial Language: en Sources: [Chris Hager]() Topics: [CI/CD](), [Continuous Deployment (CD)](), [GitHub Pages](), [Hugo](), [Travis CI](), [GitHub](), [Git](), [Go Language](), [container]() Tags: [builds](), [ci](), [continuous-deployment](), [deployment](), [git](), [github](), [github-pages](), [go](), [how-to](), [hugo](), [travis-ci]() ### AI overview A tutorial on automating Hugo static website builds and deployment to GitHub Pages with Travis CI. Builds run when changes are pushed to Git, and deployment occurs after a successful build on the master branch. ### Source excerpt This post shows how to automate building and deployment of Hugo static websites to GitHub Pages using Travis CI. Builds are automatically triggered when pushing to the Git repository, and deployment when a build on the master branch succeeds. Hugo is a static website generator written in Go, and only requires a single binary. The easiest way to run Hugo in the Travis CI container is by including the specific hugo binary with which to build the site as part of the repository (eg. ## Feature Toggles and the Unleash Framework for Continuous Deployment DevFeed: [Feature Toggles and the Unleash Framework for Continuous Deployment]() Original publisher: [Read original article]() Author: Ivar Conradi Østhus Published: 2017-03-10T16:58:36Z Content type: article Language: en Sources: [Finn.no]() Topics: [Continuous Deployment (CD)](), [CI/CD](), [Open Source](), [Framework](), [Software](), [Software as a service]() Tags: [continuous-deployment](), [deployment](), [framework](), [open-source](), [software]() ### AI overview This article explains how feature toggles separate deploying code to production from releasing features to users. It presents Unleash, an open source framework that supports user-specific activation strategies and describes how feature toggles helped FINN integrate unfinished features earlier while avoiding long-running feature branches. ### Source excerpt FINN.no is the largest online marketplace in Norway, and we take continuous deployment seriously. We are about one hundred developers deploying new code to production 978 times each week. That is 978 / 100 = 9.78 deployments to production per developer every week. In order to get to these numbers and still keep it under control, we have had to both change our development process and establish the right set of tools. In this article we introduce feature toggles and how this technique has contributed to our continuous deployment success. We will also present Unleash, an open source framework we created to support feature toggles at an enterprise scale. Unleash allows us to enable features for specific users via the activation strategies concept. Unleash is already set up and in use by multiple teams within Schibsted, including FINN, SPT Payment, and Knocker. Unleash is now also available as a Software-as-a-Service offering, making it much easier for anyone to adopt. Check it out at unleash-hosted.com Number of production deploys in "week 50" Feature Toggles 'Feature toggles' is a simple technique to separate the process of putting new code into production from the process of releasing new features to our users. In its simplest form a feature toggle is just a "if" statement in the code, guarding the new feature: if (unleash.isEnabled("AwesomeFeature")) { //magic new feature code } else { //old boring stuff } The fastest way to get started with feature toggles in your project is to use a plain old properties file. This allows you to integrate unfinished features to the master branch and hide them from users in production. A simple plain properties files was exactly how we started playing with the features toggles in FINN. We realised that feature toggles enabled us to move faster, because we were able to integrate new and unfinished features to the master branch early. This also avoids long-running feature branches that tend to be harder to merge. We learned the hard wa ## Continuous Deployment System DevFeed: [Continuous Deployment System]() Original publisher: [Read original article]() Published: 2013-08-05T00:00:00Z Content type: tutorial Language: en Sources: [HackerEarth]() Topics: [Continuous Deployment (CD)](), [Deployment](), [Git](), [bitbucket](), [Amazon EC2](), [Testing]() Tags: [bitbucket](), [continuous-deployment](), [deployment](), [git](), [server](), [servers](), [testing]() ### AI overview This article explains HackerEarth's Continuous Deployment System, which automates deployment and testing for a rapidly changing product. The system uses Bitbucket hooks, a toolchain server, commit filtering and grouping, integration testing through RabbitMQ, and deployment triggered by git push origin master. ### Source excerpt This is one of the coolest and important thing we recently built at HackerEarth. What's so cool about it? Just have a little patience, you will soon find out. But make sure you read till the end :) I will try to make this post as resourceful, and clear so that people who always wondered how to implement a Continuous Deployment System(CDS) can gain insights. At HackerEarth, we iterate over our product quickly and roll out new features as soon as they are production ready. In last two weeks, we deployed 100+ commits in production, and a major release is scheduled to be launched within a few days comprising over 150+ commits. Those commits consists of changes to backend app, website, static files, database and many more. We have over a dozen different types of servers running e.g. webserver, code-checker server, log server, wiki server, realtime server, NoSQL server, etc. And all of them are running on multiple ec2 instance at any point of time. Our codebase is still tightly integrated as one single project with many different components required for each server. And when there are changes to codebase, all the related servers and components need to be updated when deploying in production. Doing that manually would have just driven us crazy, and would have been a total waste of time! See the table of commits deployed on a single day, and that too on lighter day! With such speed of work, we needed a automated deployment system along with automated testing. Our implementation of CDS helps the team to roll out features in production with just a single command: git push origin master. Also, another reason to use CDS is that we are trying to automate the crap out of everything and I see us going in right direction. ####CDS Model The process begins with developer pushing bunch of commits from his master branch to remote repository which in our case is setup on Bitbucket. We have setup a post hook on Bitbucket, so as soon as Bitbucket receives commits from developer, it genera ## Package Management conflicts Continuous Delivery DevFeed: [Package Management conflicts Continuous Delivery]() Original publisher: [Read original article]() Author: mick Published: 2013-06-26T20:42:28Z Content type: article Language: en Sources: [Finn.no]() Topics: [Package Management](), [CI/CD](), [Continuous Deployment (CD)](), [API](), [Code]() Tags: [api-design](), [continuous-delivery](), [continuous-deployment](), [dependencies](), [package-management](), [transitive-dependencies]() ### AI overview The article examines tensions between package management and Continuous Delivery. It explains that package releases cannot be undone once downloaded, whereas deployment changes can be rolled back, while API design and modularity limit how far Continuous Delivery can be applied. It proposes emphasizing safety and API design lower in the stack and delivery speed higher in the stack. ### Source excerpt The idea of package management is to correctly operate and bundle together various components in any system. The practice of package management is a consequence from the design and evolution of each component's API. Package management is tedious but necessary. It can also help to address the 'fear of change'. We can minimise package management by minimising API. But we can't minimise API if we don't have experience with where it comes from. You can't define for yourself what the API of your code is. It is well beyond that of your public method signatures. Anything that with change can break a consumer is API. Continuous Delivery isn't void of API despite fixed and minimised interfaces between runtime services, each runtime service also contains an API in how it behaves. The big difference though is you own the release change, a la the deployment event, and if things don't go well you can roll back. Releasing artifacts in the context of package management can not be undone. Once you have released the artifact you must presume someone has already downloaded it and you can't get it back. The best you can do it release a new version and hope everyone upgrades to it quickly. Push code out from behind the shackles of package management take advantage of continuous delivery! Bearing in mind a healthy modular systems design comes from making sure you got the api design right - so the amount one can utilise CD is ultimately limited, unless you want to throw out modularity. In general we let components low in the stack "be safe" by focusing on api design over delivery time, and the opposite for components high in the stack. High in the stack doesn't refer to front-end code Code at the top of the stack is that free of package management and completely free for continuous deployment. Components with direct consumers no longer sit at the top of the stack. As components consumers multiple, and they become transitive dependencies, they move further down the stack. Typically entrop