Selling Dagger to dev teams

[faint flame]

Hello! You never know where resistance to change might arise from 🙂

It all depends on the nature of the objections. What concerns or criticism are you hearing?

[final cliff]

The main friction points appear to be that (and i can provide some of my feels on each of these as well, but i’ll limit to just their points here):

1. it does not provide value beyond github actions, which is our chosen cicd function platform.

2. There are relatively few people who know Go and so the supportability of the dagger module that i poc’ed is a point of contention.

3. The ongoing maintenance burden from introducing dagger into the ecosystem

1. I can’t even begin to express the value of being able to run the exact pipeline that will be run by the orchestrator locally. the development cadence is much better than having to push and then run a test harness and hope to god you are emitting the output you need to fix the problem. it also solves a lot of local dependency chains that are typically poorly documented and more painfully resolved. there’s also the caching which we are, at current, not accounting for because we are using ephemeral runners, but would absolutely be on the agenda (especially with the depot integration)

2. i personally don’t understand the fixation with go as they can author in python and typescript. i used what i was comfortable with and the sdk isn’t really relevant when you are importing the module. 🤷‍♂️. especially when our current posture gha is mostly shell 😢

3. I don’t particularly have much here.

[faint flame]

For 1. what can help is focusing on end-to-end builds, and end-to-end tests.

• How do you get a complete build that involves multiple platforms and toolchains? Can you run it locally and in CI? For large software projects that's usually a big pain. The more heterogeneous the stack, the bigger the pain

• How do you get a complete end-to-end environment? Same thing, usually it's neither reproducible nor portable

So I would recommend avoiding "Dagger vs. Github Actions" as a head-to-head comparison, but instead emphasizing the value of having portable & repeatable builds that work across all platforms

For language objection: for sure you should make sure each language silo gets a dagger module developed in its favorite language. That dramatically increases chances of adoption. We made dagger multi-language specifically to make this possible. A python module can import a Go module, etc

For 3: no point in attacking that one directly. It's always true that adopting a new tool has a cost. If you're arguing over that cost, you've already lost. What you want is for people to be so excited about the benefits (because it solves a hair on fire problem in their builds or tests) that they don't care about the adoption & maintenance cost.

[final cliff]

so at no point have i argued either cost or complexity. i don’t think either focus on the core value that is being sought

and i am actually trying to sidestep the gha vs dagger argument. my dagger module functions are getting gh action wrappers to ensure that even if people don’t want to develop dagger workflows, they have an easy path to integrating them

i see no reason it has to be an either/or fight

full disclosure, i am on a platform engineering team tasked with developing cicd for the 80% use case.

those were all great points that i am going to add to my outline, btw

[faint flame]

looks like you already have the right approach overall!

[final cliff]

so ty!

[faint flame]

clarifying the relationship to the CI platform, and looking for hair-on-fire problems related to builds and tests seems like it might help

[final cliff]

i would love to say that i could develop modules in other sdks, but alas, i am a one-language pony 😇

[hard bison]

@final cliff I've had a variety of responses, ranging from negative to indifferent to very positive. Dagger isn't exactly a paradigm shift, but it's enough of a shift that I think natural reluctance to change kicks in for many.

Something that really helped for me was focusing on testing. How do you test bash-in-yaml-in-ci-platform? The answer for almost all orgs I've worked with was some variation of "we don't", "manually, somewhere else", or some form of "with difficulty, and certainly not with any degree of certainty".

When CICD starts to look a lot more like application development then we're able to both learn and copy from decades of optimising the SDLC for productivity, delivery, and safety, at scale, which common CICD just flat out does not have. Honestly CICD is, in most orgs, held to a lower standard than actual software development, and Dagger really helps close the gap.

TLDR: Safety (provided by significantly higher levels of testability) leads to faster, more confident engineers, which leads to faster, more resilient delivery.

[final cliff]

also great points - thank you both!