4 ms·

> My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, I call this “isomorphic CI” — ie: as long as you set the

by ukoki 2y ago

> My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, I call this “isomorphic CI” — ie: as long as you set the correct env vars, it should run identically on GitHub actions, Jenkins, your local machine, a VM etc

reactordev 2y ago
This is the only DevOps way. Abstract the build into a single step.
- vvillena 2y ago
  And yet, you would be surprised at the amount of people who react like that's an ignorant statement ("not feasible in real world conditions"), an utopic goal ("too much time to implement"), an impossible feat ("automation difficults human oversight"), or, my favorite, the "this is beneath us" excuse ("see, we are special and this wouldn't work here"). Automation renders knowledge into a set of executable steps, which is much better than rendering knowledge into documentation, or leaving it to rot in people's minds. Compiling all rendered knowledge into a single step is the easiest way to ensure all elements around the build and deployment lifecycle work in unison and are guarded around failures.
  - necovek 2y ago
    Building a Github-specific CI pipeline similarly transfer it into a set of executable steps. The only difference is that you are now tied to a vendor for executing that logic, and the issue is really that this tooling is proprietary software (otherwise, you could just take their theoretical open source runner system and run it locally). To me, this is mostly a question of using non-open-source development tools or not.
jamesfinlayson 2y ago
Yep. I remember at a previous company multiple teams had manually created steps in TeamCity (and it wasn't even being backed up in .xml files). I just did my own thing and wrapped everything deploy.sh and test.sh and when the shift to another system came... well it was still kind of annoying, but at least I wasn't recreating the whole thing.
NilMostChill 2y ago
i like this term

by ukoki 2y ago

reactordev 2y ago

This is the only DevOps way. Abstract the build into a single step.

vvillena 2y ago
And yet, you would be surprised at the amount of people who react like that's an ignorant statement ("not feasible in real world conditions"), an utopic goal ("too much time to implement"), an impossible feat ("automation difficults human oversight"), or, my favorite, the "this is beneath us" excuse ("see, we are special and this wouldn't work here"). Automation renders knowledge into a set of executable steps, which is much better than rendering knowledge into documentation, or leaving it to rot in people's minds. Compiling all rendered knowledge into a single step is the easiest way to ensure all elements around the build and deployment lifecycle work in unison and are guarded around failures.
- necovek 2y ago
  Building a Github-specific CI pipeline similarly transfer it into a set of executable steps. The only difference is that you are now tied to a vendor for executing that logic, and the issue is really that this tooling is proprietary software (otherwise, you could just take their theoretical open source runner system and run it locally). To me, this is mostly a question of using non-open-source development tools or not.

jamesfinlayson 2y ago

Yep. I remember at a previous company multiple teams had manually created steps in TeamCity (and it wasn't even being backed up in .xml files). I just did my own thing and wrapped everything deploy.sh and test.sh and when the shift to another system came... well it was still kind of annoying, but at least I wasn't recreating the whole thing.

NilMostChill 2y ago

i like this term