Hi everyone 👋 I see a lot of people duplicating their CI/CD workflows for each service in their repos and more stuff like this. copy, paste, tweak for each microservice or project. It’s not only messy but also makes maintenance a nightmare. Configuration duplication is just as bad as code duplication, so why not think about your workflows like reusable functions? Instead of duplicating entire workflows for every service, reusable workflows are a cleaner and more scalable approach. In GitHub Actions, you can create a single workflow in one file and call it across multiple services. As a platform engineer how do you approach this, if you tackle this at all?

We're doing pretty much that via a central repository that contains shared workflows and a few custom actions (where necessary) so we can make it easier for teams to use jobs without copypasta Makes it easier for the teams because we can tailor the workflow inputs to only what is needed, and easier for us to tweak/maintain both custom and community actions

What I've gone through my dev time reusable code for mostly kind of seen as if not defined to many as changing the parameters and making it what you need and to want it to be done, as you said correctly becomes a maintenance nightmare, from my dev time we started using a pattern like a factory which whole purpose was job call the factory to execute the implementation based on the parameters passed, Configuration duplication is far scarier than ever before b/c of its declarative nature, reusable workflows if not discussed kind of seen as asking for different tasks based on parameters passed, but I kind of tend to see reusable workflows as idempotents otherwise these days where policy as code prevent and mixed to prevent what should not be in production if not compliant otherwise, maintenance and troubleshooting can take hours and days, what we started to do some research on since configuration code somewhat becomes PL to incorporate design pattern from SE world to add it an abstraction layer on top reusable workflow and make it predictable task,

"central repository with shared workflows" exactly how i would say @Andrew Kirkpatrick. We have the best success with this approach

Platform: automation, and composable, loosely coupled capabilities all the way down. Shared libraries approach is the way to go, but be careful about tight coupling that makes it difficult to make changes and enhancements. We use code generation extensively in conjunction with other techniques. So we generate applications with their manifests for “all the things”, but those manifests are really just calls to shared functions, as you put it.

We have a set of shared workflows and actions that are used by all services. You still wind up needing very similar .github workflows in each service repo to orchestrate the various workflows. But the true complexity/detail is in the shared repos. And its far easier to change the shared workflow and then just bump the version number in the service's workflows, than it is to copy paste the workflow changes to all the service workflows. I feel like said workflow so many times there that it lost all meaning lol

Hey there! Coming late to the party hehe, thanks for your insights. @Andrew Fong, The website you shared is not loading for me. I'm behind a VPN connected to a US Server.