You’re in charge of establishing a department-wide deployment automation capability. Your fellow developers are excited about it, and their managers are too. There is no shortage of ideas on how it might work:
- “Let us create our own workflows!”
- “We should be able to configure our own servers.”
- “It should be able to deploy from Nexus, Artifactory, S3, or whatever we choose.”
- “We can finally use the app versioning scheme my team likes.”
- “My team should get to do parallel installs if we want”
- “We should have open APIs so anybody can execute their own deployment solution.”
- “Each team should be able to configure the middleware for their application’s needs.”
- Value-added flexibility can be represented by a middleware option between Tomcat, JBoss and Glassfish. Each solution provides different features to the development team and they should have the ability to choose the best match (within reason) for developing to application requirements. Easy enough, there is value to the options.
- Gratuitous flexibility can be represented by allowing multiple install directory variations for each Tomcat app. SysAdmins usually have a preference and sometimes make it a very passionate preference. Although the configuration matters, it should support automation and security, not personal preference. There is no inherent value gained by allowing your environment to have different install directories such as /opt, /app, /u01. In fact, allowing options creates complexity for install scripts, logging, permissions, service accounts, monitoring etc. Pick one and restrict the rest.
Reference: DevOps: Flexible configuration management? Not so fast! from our JCG partner Willie Wheeler at the Skydingo blog.