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.