All,
I am scratching my head over this question for a while now, but can’t seem to find a good answer. However this should be a pretty common question/concern. Maybe someone can tell me how they solved this:
- We have a packaged software that we deploy with the customer as well as host for them. We now move to AWS for hosting and would like to automate with Ansible.
- Customers we host run different versions of the software and therefore there could be changes that require changes into the Ansible scripts as well
- The application is a tiered Java application with several servers involved during runtime, single-tenant.
- In AWS we will have some servers that are shared between customers (monitoring, front-ends, DB) and some that are dedicated (application server)
My main question: How should I organize the Ansible scripts artifacts as well as the application artifact so I support all current deployments while ensuring that changes don’t break existing deployments?
When should I create AMIs? Through Ansible during development? Or always create the environment from vanilla AMIs?
Alternatives:
- I could create branches whenever we introduce changes to the scripts. My Ansible host in AWS would contain all active branches (subdirectories)
- Maintain backwards compatibility in the Ansible scripts. But that can get pretty nasty over time. Also testing older releases will become messy.
- Include (some) ansible scripts in the release package so that there is only one artifact, one changes pipeline.
Maybe you can help me with this by sharing how you solved similar scenarios.
Thanks,
Timo