We recently introduced CI/CD on one of our projects and fortunately didn't meet much resistance. In our case the benefits to the devs were very clear: we were able to build, test, and deploy a C++ app across multiple architectures and platforms in parallel automatically on each push. We even measured the time savings and everyone was able to see the clear benefits.
In your case I would try to make the benefits clear (e.g. measure the time savings of implementing CI/CD) and then work to address colleague concerns with some sort of compromise. Some possible solutions for the specific concern you mentioned include:
Commits which introduce small breaking changes could be pushed with CI-skip flag
Set a policy of only pushing working versions of the code and set CI to only build the HEAD of the pushed state
Use feature flags to disable new features until they are ready
Only run CI on merge requests which represent a completed feature
Admit that CI/CD is not cost free but work with your colleagues to come up with a workflow which provides a net gain.
I'm a software engineer working in the intellectual property space. When I'm not at work, I'm at home with the family which includes a wife, son, two cats, guitars, and a varying number of banjos.
Thanks, Evan, those are all great pieces of advice, and the CI-skip is actually new to me! We currently have a rudimentary feature toggle in place that keeps things turned off, per environment, until they're ready for prime time. Eventually, I think something like LaunchDarkly would be a useful next step. I'm going to run a couple of these by my teammate who has raised the concerns. He's our resident Git expert as it is and has a lot of interest in automation/DevOps, so I think he could really help us come up with something that works well for us. I appreciate the tips; I'm going to email them to my work address now and start digging in a bit more in the morning. Now, it's time to go forth and stop thinking about work :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We recently introduced CI/CD on one of our projects and fortunately didn't meet much resistance. In our case the benefits to the devs were very clear: we were able to build, test, and deploy a C++ app across multiple architectures and platforms in parallel automatically on each push. We even measured the time savings and everyone was able to see the clear benefits.
In your case I would try to make the benefits clear (e.g. measure the time savings of implementing CI/CD) and then work to address colleague concerns with some sort of compromise. Some possible solutions for the specific concern you mentioned include:
CI-skip
flagHEAD
of the pushed stateAdmit that CI/CD is not cost free but work with your colleagues to come up with a workflow which provides a net gain.
Thanks, Evan, those are all great pieces of advice, and the CI-skip is actually new to me! We currently have a rudimentary feature toggle in place that keeps things turned off, per environment, until they're ready for prime time. Eventually, I think something like LaunchDarkly would be a useful next step. I'm going to run a couple of these by my teammate who has raised the concerns. He's our resident Git expert as it is and has a lot of interest in automation/DevOps, so I think he could really help us come up with something that works well for us. I appreciate the tips; I'm going to email them to my work address now and start digging in a bit more in the morning. Now, it's time to go forth and stop thinking about work :)