#Hey ho Dagger-Team!

1 messages · Page 1 of 1 (latest)

tranquil vortex
#

We've recently gone through pretty much the same transition at Lunar. (blog post pending 🙂 )

Our setup was: pretty much the same jenkins pipeline for up to 500 services. As such it was filled with a whole bunch of opt outs, changes and whatnot.

Our philosophy is that developers shouldn't care whether their pipeline runs in Jenkins, GitHub actions with dagger etc.

So our questions were on a higher level of abstraction, I.e. what do our developers value most in a pipeline.

  • Speed, Reliability, features, flexibility etc.

  • Which features of golang are required for their workflow: (give us suggestions), we then opened a poll afterwards so we could track which features were the most important.

After that we began slowly moving pipelines to github actions with dagger. First we ran them in parallel, where only jenkins was required, at this stage we just gathered data whether it was fast enough, and as reliable.

Then we slowly migrated services onto requiring github actions and finally removing the jenkins webhook from the service.

At this point we could add more features to our pipelines and think about what our CI journey looks like.

We have the extra benefit of using our open-source shuttle tool, which supports pulling different dagger pipelines in at different stages of maturity. I.e. stable, experiemental, latest etc. This made us able to test new features out without having to release to 500 pipelines at once, which made the rollout a whole lot easier.

deep cedar
#

Thanks for the feedback. Sounds very similar to our case 😉

I like your ideas about the abstraction with speed, reliability, etc.
We also think about including questions regarding training. E.g.: "Would you rather have a workshop/training/videos/etc. for learning pipelines"

Perhaps you could also share, how you tackle those? Meaning, how do you train your colleagues about using the pipelines the right ways etc.?

tranquil vortex
#

Our case is a bit special. Our developers don't touch our pipelines at all. So no need for training.

But the way of educate each other is simply to have documentation and examples for our different modules. I.e. this is how you use x.y.z.

We've also integrated dagger into our cli tool which developers are already familiar with, so there is no difference for them there either.

Normally we would have run bash scripts if you ran shuttle run integration_test locally.

Now if you run shuttle run integration_test it instead kicks off the dagger pipeline for our integration_test module 😄

deep cedar
#

Nice! This is also something we thought of. using dagger and the caching mechanism (via the cli too) to provide datasets or similar stuff.

Thansk for the info 🙂

floral solar
#

how do you handle private modules?

loud trellis
loud trellis
#

@deep cedar I will DM you as well because @nocturne tusk and I would love to learn more about your use case and help support you with a POC for your team to help convince them 🙂

deep cedar
loud trellis
#

I love your mindset on all of this and looking forward to chatting!