*What* Provides a way to visualize, orchestrate differential deployments in Octopus. *Branch Deployment* Will deploy all components that have SemVer pre-release that matches given branch. The latest component will be selected. If the target environment already has the exact component it will be skipped. All components that do not have a matching SemVer pre-release will then match no SemVer pre-release (i.e. master). The latest component will be selected. If the target environment already has the component it will be skipped. This is often used for testing a feature branch. Features can span multiple repositories which means multiple components. *Mirror Environment Deployment* Will deploy all components from source environment to target environment. The exact component is matched. If the target environment already has the exact component it will be skipped. This is often used for promoting a product from one environment to another or when developers want to debug a product on their own machines. *Redeployment* Will redeploy all components. The exact component is matched. This is often used for redeploying when settings/feature toggles have changed. Why When running micro-services architecture one of the downsides is that there is plenty of stuff to deploy. To reduce this tax you need to ensure as much as possible is automated. Octopus goes a long way to making a great experience, but there are a few short comings. Deployment Taxes: It is often difficult to see how components are dependent on each other. The ideal situation is a graphical graph which shows component deployment dependencies. Having one giant octopus deployment project is not feasible either. Often we don't want to deploy everything as this takes ages. The ideal situation is a differential deployment. It will only deploy what has not already been deployed. There appears to be no way of calling other deployments from a deployment in Octopus. This is due to Octopus will block the deployment. So you can't call the Octopus API and wait until the deployment is finished as Octopus will only start running the task once the wait is finished. The ideal situation is a way to call deployments from deployments or have something that can orchestrate this.