world's fastest delivery pipeline for Sitecore on Azure

Editor's Notes

• #6: Developer satisfaction :D 30x deployments a day – Because you can doesn’t mean you should :D Need for Speed High quality deployments (Automatic testing) No manual interactions Zero downtime Always green (including upgrades!) Easy upgrades Standard tooling (Azure DevOps tasks, PowerShell, MSBuild) Standardize deployments Productivity Smaller increments
• #7: Nothing strange over here. There are numerous ways to define requirements, develop your code, verify your code, deploy the packages, verify the quality and release it to production. Every step has some quality gates. I am not talking about all the decoration around the build and deployment, that is hard enough ;)
• #11: It can be done in various ways. And without any guidance, those various ways + the ones that you didn’t think of, will exist in your company. Builds can’t be standardized, 3rd party tooling can’t be standardized, deployment can’t be standardized. People are not exchangeable. Thinkk of Zip, Ship, web deploy, TDS, TDS package explorer, Unicorn, robocopy and database copies from local development to production. Thinks will go wrong. This is no structure; it’s total chaos.
• #12: 90 – 4320 unique ways to deploy Sitecore
• #13: Doesn’t tell anything about the granulatiry of modules, so it can’t be compared to helix. It tells something, however, about reusability. Doesn’t tell anything about packaging as well. Logical view, no physical ;)
• #16: Be in control of the sitecore versions, patches and configuration While having the Flexibility of adding own configuration Single package traversing the pipeline – if possible Developer satisfaction :D 30x deployments a day – Because you can doesn’t mean you should :D Need for Speed High quality deployments (Automatic testing) No manual interactions Zero downtime Always green (including upgrades!) Easy upgrades Standard tooling (Azure DevOps tasks, PowerShell, MSBuild) Standardize deployments Productivity Smaller increments
• #19: Deploy baseline, then application Important changes such as secyrity patches, SHA512 changes, et cetera Restore basics, remove all yml, business application specific binaries and reinstall. This way you are sure that you are not keeping old yml files, patch files, binaries or other resources
• #20: Web deploy is a way to package, archive and deploy web applications. Msdeploy is being used everywhere: ARM templates, azyre app service deploy, Visual studio, web matrix, etc. Used to backup/deploy/sync/remove applications, create new packakges. Offers functionality to deploy databases: that’s exactly what SIF and ARM templates are doing. But you don’t want to do that during deployment. Could even be used to Modify packages -> blog
• #24: Good voor provisioning, but a bitch to do over and over again. Hence, there is a problem with redeploying an application, as it would reinstall the database.
• #27: Two builds: Sitecore baseline: we can continuously incorporate the new baseline, if needed business application Both get deployed
• #28: the amount of parameters has been reduced to just one; But what happened to the connectionstring parameters? How to set for example the EXM keys for the web.config?
• #49: XDT can be applied on other XDT files (e.g. config transformations)
• #56: Could be done in powershell But you would have to build multithreading YAML to maintain releases?
• #59: Seen before on build
• #62: 4 agents running Only deploying for a certain configuration
• #64: Sync doesn’t increase much after S2, nor does elastic pool – cost efficient
• #73: Parallel deployments using multi configuration Turn on dilithium Bigger doesn’t mean better Merge packages