<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Deployment Strategies on Engineering Leadership in AI &amp; Software</title>
		<link>https://engineering-leadership-preview.hinshelwood.com/tags/deployment-strategies/</link>
		<description>Recent content in Deployment Strategies on Engineering Leadership in AI &amp; Software</description>
		<generator>Hugo</generator>
		<language>en</language>
		
		
		
		
			<lastBuildDate>Tue, 16 Jun 2026 17:40:35 +0000</lastBuildDate>
		
			<atom:link href="https://engineering-leadership-preview.hinshelwood.com/tags/deployment-strategies/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Stop Promoting Branches</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/articles/stop-promoting-branches/</link>
				<pubDate>Thu, 06 Feb 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/articles/stop-promoting-branches/</guid>
				<description>Promoting code through multiple environment branches slows delivery, increases risk, and adds unnecessary complexity. Instead, use simple branching models like GitHub Flow for continuous delivery or Release Flow if you must support multiple live versions; avoid outdated models like Git Flow and never rely on reverse integration. Focus on merging changes directly into main, use feature flags for releases, and keep branching lightweight to deliver value faster.</description>
			</item>
			<item>
				<title>How to Build for Business Resilience and Continuity</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/articles/how-to-build-for-business-resilience-and-continuity/</link>
				<pubDate>Mon, 26 May 2025 09:00:00 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/articles/how-to-build-for-business-resilience-and-continuity/</guid>
				<description>Building business resilience requires intentional design, strong observability, and aggressive decoupling so failures do not cascade across systems. Empower teams to act quickly, treat deployments as routine, and design for fast recovery using practices like chaos engineering and circuit breakers. Make resilience a core part of your culture and operations, not a one-time project, and use real metrics to guide continuous improvement.</description>
			</item>
			<item>
				<title>Still Deploying Manually? Why Automation Is the Bare Minimum for Modern Engineering (and Your Business Survival)</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/videos/still-deploying-manually-why-automation-is-the-bare-minimum-for-modern-engineering-and-your-business-survival/</link>
				<pubDate>Mon, 11 Aug 2025 07:00:00 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/videos/still-deploying-manually-why-automation-is-the-bare-minimum-for-modern-engineering-and-your-business-survival/</guid>
				<description>Manual deployments put your business at serious risk due to inevitable human error, as shown by real-world failures that have caused massive financial losses. Automation of builds, deployments, tests, and quality checks is now the minimum standard for professional software development, enabling faster, safer, and more reliable releases. To protect your business and deliver value consistently, eliminate manual steps and automate every part of your delivery pipeline as soon as possible.</description>
			</item>
			<item>
				<title>Rethinking Dev-Test-Staging-Production Pipelines for Safety</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/signals/rethinking-dev-test-staging-production-pipelines-for-safety/</link>
				<pubDate>Fri, 21 Feb 2025 16:30:30 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/signals/rethinking-dev-test-staging-production-pipelines-for-safety/</guid>
				<description>Traditional Dev-Test-Staging-Production pipelines give a false sense of security because staging environments do not truly reflect production, leading to missed issues and wasted resources. Modern teams should focus on releasing to small user groups in production and using real feedback to guide rollouts. Consider shifting from heavy pre-release testing to faster, data-driven feedback in production to improve safety and efficiency.</description>
			</item>
			<item>
				<title>Why Engineering Teams Use Staging Environments for Risk Reduction</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/signals/why-engineering-teams-use-staging-environments-for-risk-reduction/</link>
				<pubDate>Fri, 14 Feb 2025 16:30:01 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/signals/why-engineering-teams-use-staging-environments-for-risk-reduction/</guid>
				<description>Staging environments are intended to reduce risk but often lead to wasted time, delayed feedback, and extra costs without truly preventing failures. Modern practices like feature flags, progressive rollouts, and real-time monitoring can help teams deploy safely to production while reducing waste. Consider whether maintaining staging environments is actually benefiting your team or just adding unnecessary overhead.</description>
			</item>
			<item>
				<title>Best Branching Strategies for Development Teams Explained</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/signals/best-branching-strategies-for-development-teams-explained/</link>
				<pubDate>Tue, 25 Feb 2025 16:30:02 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/signals/best-branching-strategies-for-development-teams-explained/</guid>
				<description>Using separate branches for each environment increases complexity and slows feedback, making it harder to deliver value quickly. Teams should use branches to manage work in progress and rely on feature flags and progressive rollouts to control what users see. Review your current branching approach and consider simplifying it to speed up delivery and reduce risk.</description>
			</item>
			<item>
				<title>There a common belief that rollback is the ultimate safety net</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/signals/there-a-common-belief-that-rollback-is-the-ultimate-safety-net/</link>
				<pubDate>Thu, 13 Feb 2025 15:53:38 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/signals/there-a-common-belief-that-rollback-is-the-ultimate-safety-net/</guid>
				<description>Relying on rollback as a safety net is risky, especially for stateful applications where it can cause data issues and failures. Safer approaches include progressive delivery methods like feature flags and canary releases, which help detect and limit problems early. Teams should focus on making deployments safe to fail rather than assuming rollback will fix mistakes.</description>
			</item>
			<item>
				<title>Deploying Windows OS Directly to Production: Then vs Now</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/signals/deploying-windows-os-directly-to-production-then-vs-now/</link>
				<pubDate>Sat, 22 Feb 2025 16:30:00 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/signals/deploying-windows-os-directly-to-production-then-vs-now/</guid>
				<description>Microsoft now deploys Windows updates directly to production using a gradual, ring-based rollout that starts with internal users and expands outward, guided by real-time feedback and telemetry. This approach catches issues early and enables safe, incremental releases even across complex environments. Development managers should consider adopting similar staged deployment strategies to improve release quality and responsiveness.</description>
			</item>
			<item>
				<title>Branch promotion is a relic of slow, manual software delivery</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/signals/branch-promotion-is-a-relic-of-slow-manual-software-delivery/</link>
				<pubDate>Sat, 08 Feb 2025 16:30:00 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/signals/branch-promotion-is-a-relic-of-slow-manual-software-delivery/</guid>
				<description>Branch promotion slows down delivery and adds risk, while modern teams merge changes into the main branch as soon as they are ready and use feature flags to separate deployment from release. Testing in production-like environments and instant rollbacks improve speed and safety. Focus on managing the flow of work, not branches, to streamline delivery.</description>
			</item>
			<item>
				<title>Building a release pipeline with Release Management with Visual Studio 2013</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/articles/building-a-release-pipeline-with-release-management-with-visual-studio-2013/</link>
				<pubDate>Tue, 18 Feb 2014 16:30:59 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/articles/building-a-release-pipeline-with-release-management-with-visual-studio-2013/</guid>
				<description>Explains how to set up a scalable release pipeline using Release Management in Visual Studio 2013, covering continuous release, feedback environments, and DevOps practices.</description>
			</item>
			<item>
				<title>Staging Environments Do Not Prevent Production Failures</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/signals/staging-environments-do-not-prevent-production-failures/</link>
				<pubDate>Fri, 28 Feb 2025 16:30:01 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/signals/staging-environments-do-not-prevent-production-failures/</guid>
				<description>Staging environments do not truly prevent production failures because they cannot fully replicate real-world conditions, often giving teams a false sense of security. Leading teams now deploy changes incrementally to real users in production, using monitoring and automated safeguards to catch issues early. Consider shifting focus from pre-production testing to safer, controlled releases in production to reduce risk and respond faster to problems.</description>
			</item>
			<item>
				<title>Release Management with Team Foundation Server 2012</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/articles/release-management-with-team-foundation-server-2012/</link>
				<pubDate>Wed, 24 Apr 2013 17:38:24 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/articles/release-management-with-team-foundation-server-2012/</guid>
				<description>Explains how to automate and streamline software release management using Team Foundation Server 2012, Lab Management, and Octopus, focusing on build, deployment, and quality.</description>
			</item>
			<item>
				<title>Unlocking Continuous Delivery: How Feature Flags Transform Software Development</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/videos/unlocking-continuous-delivery-how-feature-flags-transform-software-development/</link>
				<pubDate>Thu, 16 Jan 2025 06:45:00 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/videos/unlocking-continuous-delivery-how-feature-flags-transform-software-development/</guid>
				<description>Feature flags enable teams to release new features incrementally, gather user feedback early, and quickly respond to issues, supporting safer and more frequent deployments. Real-world examples like Azure DevOps show that this approach allows for controlled rollouts, continuous monitoring, and ongoing improvements based on user input. Development managers should consider adopting feature flags to improve delivery speed, reduce risk, and ensure features better meet user needs.</description>
			</item>
			<item>
				<title>Create a Release Management pipeline for Professional Developers</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/articles/create-a-release-management-pipeline-for-professional-developers/</link>
				<pubDate>Thu, 04 Dec 2014 12:15:56 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/articles/create-a-release-management-pipeline-for-professional-developers/</guid>
				<description>This guide walks through setting up an automated release management pipeline using TFS/VSO and Azure, showing how to build, deploy, and parameterize a legacy web app across multiple feedback environments. Key takeaways include the importance of automating builds and releases, using environment-specific parameters, and streamlining approvals for smoother deployments. Development managers should consider investing time upfront to automate and parameterize their pipelines, as this reduces manual errors and accelerates feedback cycles.</description>
			</item>
			<item>
				<title>Continuous Delivery</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/tags/continuous-delivery/</link>
				<pubDate>Fri, 21 Mar 2025 13:37:32 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/tags/continuous-delivery/</guid>
				<description>Continuous Delivery is a software delivery practice that focuses on producing software in short, reliable cycles, enabling teams to release updates at any time. Originating from the need for more efficient and responsive software development processes, it involves delivering small, incremental improvements directly to users from the initial stages of development. This approach, as defined by Jez Humble, emphasises the ability to safely and quickly implement changes, such as new features, configuration adjustments, and bug fixes, into production. The importance of Continuous Delivery lies in its capacity to facilitate rapid validation of assumptions and collection of user feedback, which are crucial for refining products and achieving valuable outcomes. By automating essential processes like testing, integration, and deployment, Continuous Delivery not only mitigates the risk of errors but also enhances software quality and accelerates the time it takes to deliver value to users. Teams that adopt this practice can more effectively respond to market demands and stakeholder input, thereby fostering a culture of continuous learning, innovation, and adaptability within their organisations.</description>
			</item>
			<item>
				<title>Deployment Strategies</title>
				<link>https://engineering-leadership-preview.hinshelwood.com/tags/deployment-strategies/</link>
				<pubDate>Tue, 11 Feb 2025 10:17:24 +0000</pubDate>
				<guid>https://engineering-leadership-preview.hinshelwood.com/tags/deployment-strategies/</guid>
				<description>Deployment strategies are systematic approaches that organisations utilise to release software into production, balancing the need for speed with risk management. These strategies are essential for enabling teams to deliver value in a predictable and sustainable manner, facilitating rapid iterations and continuous feedback. Techniques such as blue-green deployments, canary releases, and rolling updates help mitigate the impact of potential failures, allowing teams to address issues swiftly without causing significant disruption to users. The effectiveness of deployment strategies lies in their capacity to cultivate a culture of experimentation and learning, encouraging continuous improvement where each deployment provides insights for refining processes. This approach enhances operational efficiency and aligns with Agile and DevOps principles, fostering collaboration and shared responsibility among cross-functional teams. Furthermore, well-defined deployment strategies contribute to a resilient organisational structure, enabling teams to adapt to evolving market demands and technological changes. By prioritising safe and efficient releases, organisations can maintain a competitive advantage while ensuring customer satisfaction remains central to their product development efforts. Ultimately, the integration of deployment strategies into the broader organisational framework supports sustainable growth and reinforces the importance of delivering value through strategic software releases.</description>
			</item>
	</channel>
</rss>
