Learnings from Deployment technologies: 

Introduction: The following article summarizes some learnings from deployment technologies that serve to take an organization’s software redistributable, package it and deploy it so that the software may run in different environments and as separate instances. They evolve from time to time and become narrowed to the environments to which they serve. For example, earlier there was WixSharp to build MS for installing and uninstalling applications or tarball on Linux for the deployment of binaries as an archive. Now, we have a lot more involved technologies that deploy to both on-premises and the cloud. Some of the salient learnings from such technologies are included here and this article continues from the previous discussion here. 

Description: 

An introduction to WixSharp might be in order. It is a language for writing Microsoft installers (MSI) that generates Wix extension files that describe the set of actions to be taken on a target computer for installing, upgrading, or rolling back a software.  The artifacts are compiled with an executable called candle and therefore the artifacts have a rhyming file extension as Wix. WixSharp makes it easy to author the logic for listing all the dependencies of your application for deployment. It converts the C# code to wxs file which in turn is compiled to build the MSI. There are a wide variety of samples in the WixSharp toolkit. Some of them require very few lines to be written for a wide variety of deployment time actions. The appeal in using such libraries is to be able to get the task done sooner with few lines of code. The earlier way of writing and editing the WXS file was error-prone and tedious. This is probably one of the most important learnings. Any language or framework that allows precise and succinct code or declarations is going to be a lot more popular than verbose ones. 

The second learning is about the preference for declarative syntax over logic. It is very tempting to encapsulate all the deployment logic in one place as a procedure. But this tends to become monolithic and takes away all the benefits of out-of-band testing and validation of artifacts. It is also involving developer attention as versions change. On the other hand, the declarative format expands the number of artifacts into self-contained declarations that can be independently validated.  

The third learning is about the reduction of custom logic. Having several and involved custom logic for organizations defeats the purpose of a general-purpose infrastructure that can bring automation, consistency, and framework-based improvements to deployment. Prevention of custom logic also prevents hacks and makes the deployments more mainstream and less vulnerable to conflicts and issues. The use of general-purpose logic will help with enhancements that serve new and multiple teams as opposed to a single customer.