We have an e-commerce application that consists of many websites and web-services which are all considered part of the e-commerce application. Our deployments typically involving updates to several, but not all websites, and each deployment could include a different set of sites. I’m trying to figure out how best to organize our OD projects. Since the overall deployment process will change every time we deploy, but will remain the same for each site, I’m considering setting up a project for each site. This will allow us to create a consistent deployment process for each site, but then I run into the trouble of orchestrating deployment of the proejcts. For example, what if one project needed to complete before a second one ran… or what if one fails, the other needs to roll back. Is anyone else in this situation, and if so, how are you approaching this dilemma…
Thanks for reaching us! There are plenty of ways to arrange projects for your scenario, depending on how fancy you want to get ;). They easiest one I could think of looks like this:
You could have 1 single deployment process with many steps on them. Let’s say you have 2 web apps and 2 services as shown on my screenshot (deploymentprocess.jpg). The first app and web service both have their own powershell steps to do stuff pre-post deployment. When you create a release, prior to start the deployment you can select which steps you want to execute. This will depend on which apps you want to deploy (see steps.jpg). This way you can easily manage dependencies between projects.
As for rollbacks, you could add a deployment step that only triggers when the previous step fails, which re-deploys the previous version of your app.
Hope this gives you some ideas on how to approach your deployment process. Feel free to keep asking questions if you need more help