Webapplicatie-deployments zijn vanaf het begin complex. Vaak begint men met ten minste een staging- en een productiedeployment. Voeg hier multi-tenancy, configuraties voor derde partij integraties zoals facebook auth of salesforce, configuraties voor cloudopslag en content distributienetwerken, continue integratie omgevingen, multi-client theming, SSL configuraties, vhost configuraties, build processen configuraties voor js frontends, achtergrondtaak configuratie, upload verwerking configuratie, de lijst gaat door... combinatoire explosie.

Bij dojo4 hebben we een rails-gebaseerde webapp stack en we gebruiken Multistage Capistrano voor deployment naar AWS EC2 nodes. We hebben een eenvoudige strategie gevonden voor het beheren van de grote verscheidenheid aan config- en deployment vereisten die onze klanten ons hebben voorgelegd. De strategie omvat een rake-taak die een RAILS_STAGE omgevingsvariabele gebruikt op basis van de Capistrano Multistage stage. We stellen een bestandsstructuur in voor deployment specifieke configs in repo_root/config/deploy/files/RAILS_STAGE die identiek is gestructureerd aan het bron repo bestandssysteem. Tijdens cap deploy, voor huidige symlink of build processen, kopieert de rake-taak recursief repo_root/config/deploy/files/RAILS_STAGE naar repo_root.

We hebben deze strategie ervaren als zeer effectief om complexe deployment configuraties schoon georganiseerd te houden op een manier die makkelijk te begrijpen is en niet veel extra complexiteit toevoegt aan een al complexe architectuur.

De gist hieronder demonstreert dit idee. Oorspronkelijk maakte deze taak gebruik van verschillende rails bibliotheken. Echter, ik kon de rails afhankelijkheden weghalen terwijl de functionaliteit van de taak behouden bleef zodat je deze kunt gebruiken met elke applicatie stack.