I try to align when possible. I think your solution is hacky and costs the company much more in the long run.
I used to try to align when possible, but lately it hasn't made a lot of sense. Keeping up with the tooling ends up being the whole job, as they change it every 6 months. This site is a side project to help out the team, not my primary job. I can't be dropping everything each time they decide to switch vendors, change up their variables names, or whatever else they decide to do.
At my company, it would involve going to weekly meetings to get all the updates and changes happening as they keep developing it, one-off meetings to get onboarded and setup... I'm pretty sure they also designed the system for Kubernetes, so I figured it would also mean containerizing the site, as it has been running on VMs for almost 10 years. Those weekly meetings also mean constant changes so things keep working (which I'm not dealing with on a different site that is going though CICD). All of this in the midst of a lot of bureaucracy. It's also a custom home grown solution, so it's not like AWS knowledge I can take with me or google.
It likely would have taken several months for little to no tangible benefit. No one on my team knows how CICD works. I'm the only one who has actually used it, and even my use has been pretty limited. It took 8 months for someone to bother to tell me where I could see build status/errors, at first they just told me to "wait about 10 minutes". There is no documentation anywhere. It's all tribal knowledge and no one seems to have the time to share it.
The only way to maintain my sanity is to not get too involved in it all. It will likely all change and go away within the next 2 years. Nothing lasts lone enough to get too invested in.
Yeah - this is key. If you're already set up to _not_ be containerised, then it's likely not going to be worthwhile unless you are actively feeling some of the pain points around running on VMs.
> It's also a custom home grown solution, so it's not like AWS knowledge I can take with me or google.
One saving grace is that a huge amount of what k8s does is abstracts the aws-ness from underneath. Running a live application on k8s on aws is three separate skills - running a live app, running apps on k8s and running k8s on aws. Two of three of those still transfer!
> fit. No one on my team knows how CICD works. I'm the only one who has actually used it, and even my use has been pretty limited.
That's fair, and it's up to you to make the call as to whether it's worth it or not. If your team aren't willing then the use cases are very limited, and that's a political fight!
> The only way to maintain my sanity is to not get too involved in it all. It will likely all change and go away within the next 2 years. Nothing lasts lone enough to get too invested in.
I've been a driver for improving developer best practices on every team I've worked on. Not everything has always stuck, but I've found that processes that can be automated tend to have high rates of success, and processes that rely on humans tend to be sidestepped. I spoke to a coworker from a previous job last night who told me that some of the process fixes I made as a cog in the wheel have survived 2 years without me there. All is not lost!
Yeah, it's just a matter of trying to pick those horses that seem likely to stick around, or that actually make like easier. Ansible is one of those; the CICD process and everything around it is not. We've changed out container platform 3 times in 3 years, and just kicked off a project to change it a 4th time, while also opening up some public cloud access if it can be justified. It's chaos.
There was also a push to build a lot of home-grown tools over the last 3-5 years. All of that is being ripped out in favor of vendor provided solutions.
The primary things that seem to stick around are the snowflakes, as sad as that is. The only teams that don't seem stressed by all that change are the ones who just do their own thing. I fought the good fight, jumping the latest and greatest stuff for over a decade and trying to put systems in place to get others to buy in as well, but I'm tired and this latest crop of tools seemed like they were destine for failure from day one.
Sounds like your system is way more efficient than the CICD... in the short term, provided you're the only person that ever needs to use it (and/or nothing ever changes)
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).
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.
To build the servers I was running on I wrote an Ansible job to install everything and copy the code down. All I had to do was add a couple flags to that to allow it to just deploy new changes. Instead of getting into the CICD pipeline I just took a few minute to make a little web front end for myself to kick off the job and watch the job status (we have Tower, but it's painfully slow). I can now deploy in 18 seconds with 1 click. Seems good enough. I'm sure I could set up a web hook to eliminate the click, but it's not a big deal.