We’re not sure where it came from, but there seems to be this general attitude among developers and operations staff – it’s acceptable for developers to pay minimal attention to how their applications are deployed and it’s acceptable for operations staff to dance around the issue by cooking up all manner of automation and configuration solutions. I like to think that many people on the ops side of the fence are just as clever and creative (if not more so) than their dev counterparts – many of them are just developers interested in solving different classes of problems. However, when developers embrace application deployment as a feature of their software, a lot of other best practices “just happen”.
This may sound obvious, but when developers take ownership of their application’s deployment process, they understand their application’s deployment process. This completely closes the knowledge gap between how developers deploy their application in a test environment and how operations deploy that same application in the production environment. This creates a sort of “horizontal consistency” in the deployment process between the development team and the operations team. Remember, consistency is a key component of a high quality deployment process.
When developers consider application deployment at every stage of development – instead of just at the end – they’re able to shake out many common issues ahead of time in their own local testing/development environment instead of in production. Issues like forgetting to set a Visual Studio project’s assembly reference to “Copy Local” so a necessary DLL doesn’t get shipped with an application’s deployable artifacts become a thing of the past. Imagine if that same problem reached production – the operations team deploys the application, but it crashes at start-up with an error like “The referenced assembly ‘Foo’ could not be resolved”. That issue would be reported as an application bug and the release would have to be rolled back. Had the developer thought about the deployment process and been able to perform the deployment exactly how the operations team performed it, that bug would’ve been caught immediately and likely fixed just as quickly.
Also, in many organizations, as developers begin to share components for common application subsystems like data access, messaging, UIs, etc. they tend to form common shared libraries for these common subsystems. These shared libraries can then be referenced by other applications to enable teams to more quickly build specific applications. By having developers consider application deployment as a feature of the application as well, the same effect begins to occur. Common deployment logic and design begins to coalesce into shared components. Then it becomes even easier to re-use the deployment logic in other applications that are of a similar “class”, like Windows Services for example. This creates a sort of “vertical consistency” between applications in your portfolio.
So if we combine this “vertical consistency” (consistent deployment processes across applications) with the “horizontal consistency” we mentioned earlier (consistent deployment processes between the development team and the operations team), you’ll see a plot emerge as seen in the chart at the beginning of the article. Then as you can see, the sweet spot you want to aim for is as close to the intersection of those two “consistency axes” as possible. Of course in reality reaching the absolute center of that chart may be impossible for certain classes of applications, but it’s still a helpful guideline to keep in mind when designing and improving your application deployment procedures.
As developers begin to embrace application deployment as a feature of their software, instead of thinking of it as a problem for the operations team to automate away, you’ll see other best practices – like we’ve listed here – begin to fall into place without even actively trying to do so.
