Thanks Michael. I’ll try and explain. If it’s not totally clear, or if you want to discuss over a call, we can certainly arrange that as well.
Take our web farm for example. We have a group of web servers that all sit behind a load-balancer. We need to deploy to each server individually, and completely, without taking down service to our clients. For this, we use a rolling deployment that cycles through one server at a time, removing each server from the load-balancer and draining all active connections. We then gracefully stop any needed services, deploy our updated packages, start services back up, and then then run some automated verification steps before returning the server to the load-balanced pool. All of this orchestration needs to occur on the child deployment project and not upstream on the parent project because we deploy several packages and each one of them cannot include steps for interacting with the load-balancer. That would not only be inefficient, but it may also cause problems whenever packages are dependent on each other.
What’s great about the Deploy A Release concept is we would no longer need to duplicate deployment steps between individual package deployment projects and complete deployment projects where we wish to deploy all packages at once. It also gives us absolute visibility into knowing which version of each package was deployed without trying to figure out which project was used for the last deployment. I sure hope that we can figure out how to make this work. Please see the diagram for a basic look at our deployment structure.
