3 ms·

> what I have would be easier for the people who it would be handed off to This seems like a very large assumption. > as they know Ansible, but have no idea h

> what I have would be easier for the people who it would be handed off to This seems like a very large assumption. > as they know Ansible, but have no idea how the CICD pipelines work I know Ansible very well. I have never set up a CICD system and would much prefer to write a bunch of Ansible playbooks for myself than to do so. My company has a CICD system already set up (I have no idea how it works internally). Setting up a pipeline and understanding how that pipeline works as a user of the CICD system is still a lot easier for me than figuring out someone else's Ansible playbook repo. Adding jobs to that pipeline is still easier than writing new Ansible tasks. CICD is almost always easier for dev teams regardless of their experience once the initial complexity of CICD setup/hosting/maintenance is already handled. If you don't already have a CICD set up, then setting up one is likely overkill for small teams. If it's already there (and maintained by a well-resourced team), use it, unless the CICD platform being used is absurdly bad for some reason (I've used a few and they have been largely fine / interchangeable).

al_borland 4y ago
It's a really basic playbook. There is a server build block that basically says install Apache, PHP, etc. and edit a few config files. And another block that just does a pull from GIT. As far as playbooks go, it's pretty basic and easy to understand. I'm not looking at it right now, but it's probably fewer than 10 tasks. It's not not one of those with thousand of lines referencing dozens of roles with complex when conditions and jinja2 on everything, like I often see. As mentioned in another comment, the site has been running on VMs for almost 10 years and not containerized. The CICD pipeline is built around Kubernetes and I have no real reason to move to Kubernetes other than to say it's running in containers. The VMs have never had issues, it's a relatively small internal site, so I don't need to worry about scaling issues. K8 is also in the process of being replaced, so moving to it now seems silly. I use the pipeline for another project I'm working on with another team and while it's needed for the stack they're using, it's bad. No one seems to know how it works, I haven't spoke to a single developer who has a positive thing to say about it, it's very poorly documented, and any time there is an issue it requires messaging a bunch of random people until you find someone with the right blend of tribal knowledge and time to help. I've had a half dozen people come to me just to find out where to see the deployment status or to know how to promote something to upper environments... and I wasn't given that information until 8 months in. Seems like it would be day 1 stuff that would be easily documented. For a hackathon they made something to do a one-click setup of a project that I would likely use, but outside of the hackathon, that feature isn't available and it would require months of work when factoring in meetings, waiting on other teams, etc to get setup without that. It's just not worth it for my use case.

al_borland 4y ago

It's a really basic playbook. There is a server build block that basically says install Apache, PHP, etc. and edit a few config files. And another block that just does a pull from GIT. As far as playbooks go, it's pretty basic and easy to understand. I'm not looking at it right now, but it's probably fewer than 10 tasks. It's not not one of those with thousand of lines referencing dozens of roles with complex when conditions and jinja2 on everything, like I often see. As mentioned in another comment, the site has been running on VMs for almost 10 years and not containerized. The CICD pipeline is built around Kubernetes and I have no real reason to move to Kubernetes other than to say it's running in containers. The VMs have never had issues, it's a relatively small internal site, so I don't need to worry about scaling issues. K8 is also in the process of being replaced, so moving to it now seems silly. I use the pipeline for another project I'm working on with another team and while it's needed for the stack they're using, it's bad. No one seems to know how it works, I haven't spoke to a single developer who has a positive thing to say about it, it's very poorly documented, and any time there is an issue it requires messaging a bunch of random people until you find someone with the right blend of tribal knowledge and time to help. I've had a half dozen people come to me just to find out where to see the deployment status or to know how to promote something to upper environments... and I wasn't given that information until 8 months in. Seems like it would be day 1 stuff that would be easily documented. For a hackathon they made something to do a one-click setup of a project that I would likely use, but outside of the hackathon, that feature isn't available and it would require months of work when factoring in meetings, waiting on other teams, etc to get setup without that. It's just not worth it for my use case.