DEV Community

Discussion on: Moving to CI/CD

Collapse
 
evanoman profile image
Evan Oman • Edited

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.

Collapse
 
rbseaver profile image
Rob Seaver (He/him)

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 :)