|
|
|
|
|
by eysi
945 days ago
|
|
To add to what's already been said: If you think about it, CI pipelines are typically a complete description of how your system is built, tested, and deployed. Which is pretty fantastic except for how walled off they are. You can't really re-use these descriptions for e.g. development, they're not vendor agnostic, and they only way to run them is by pushing your code. Maybe it's a silly analogy but it's almost like being a web dev that doesn't have a browser and needs to send their code to a friend who can tell them if that font size looks good. I think we're way over due for freeing these "blueprints" of our system from the confines of CI and making them portable and flexible. And containers are the technology that's enabling that. Full disclaimer (as always): I work at Garden[0] where we're also solving that problem but taking a slightly different approach to Dagger (it's still a DAG). Garden config is declarative and the jobs (we call them actions) have a semantic meaning. You can e.g. have a Build action of type container or a Deploy action of type Helm and Garden will figure out what to do with it. We've also put a lot of emphasis on the inner loop development story with hot reloading functionality, log streaming and more. [0] https://github.com/garden-io/garden |
|