Copied Dagger vs documentation to Europa.
Signed-off-by: kgb33 <keltonbassingthwaite@gmail.com>
This commit is contained in:
parent
cc4cabb713
commit
b68fc6f57b
47
docs/getting-started/1220-vs.md
Normal file
47
docs/getting-started/1220-vs.md
Normal file
@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
slug: /1220/vs
|
||||||
|
displayed_sidebar: europa
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dagger vs. Other Software
|
||||||
|
|
||||||
|
## Dagger vs. CI (Github Actions, Gitlab, CircleCI, Jenkins, etc.)
|
||||||
|
|
||||||
|
Dagger does not replace your CI: it improves it by adding a portable development layer on top of it.
|
||||||
|
|
||||||
|
* Dagger runs on all major CI products. This *reduces CI lock-in*: you can change CI without rewriting all your pipelines.
|
||||||
|
* Dagger also runs on your dev machine. This allows *dev/CI parity*: the same pipelines can be used in CI and development.
|
||||||
|
|
||||||
|
## Dagger vs. PaaS (Heroku, Firebase, etc.)
|
||||||
|
|
||||||
|
Dagger is not a PaaS, but you can use it to add PaaS-like features to your CICD pipelines:
|
||||||
|
|
||||||
|
* A simple deployment abstraction for the developer
|
||||||
|
* A catalog of possible customizations, managed by the platform team
|
||||||
|
* On-demand staging or development environments
|
||||||
|
|
||||||
|
Using Dagger is a good way to get many of the benefits of a PaaS (developer productivity and peace of mind),
|
||||||
|
without giving up the benefits of custom CICD pipelines (full control over your infrastructure and tooling).
|
||||||
|
|
||||||
|
## Dagger vs. artisanal deploy scripts
|
||||||
|
|
||||||
|
Most applications have a custom deploy script that usually gets the job done, but is painful to change and troubleshoot.
|
||||||
|
|
||||||
|
Using Dagger, you have two options:
|
||||||
|
|
||||||
|
1. You can *replace* your script with a DAG that is better in every way: more features, more reliable, faster, easier to read, improve, and debug.
|
||||||
|
2. You can *extend* your script by wrapping it, as-is, into a DAG. This allows you to start using Dagger right away, and worry about rewrites later.
|
||||||
|
|
||||||
|
## Dagger vs. Infrastructure as Code (Terraform, Pulumi, Cloudformation, CDK)
|
||||||
|
|
||||||
|
Dagger is the perfect complement to an IaC tool.
|
||||||
|
|
||||||
|
* IaC tools help infrastructure teams answer questions like: what is the current state of my infrastructure? What is its desired state? And how do I get there?
|
||||||
|
* Dagger helps CICD teams answer question like: what work needs to be done to deliver my application, in what order, and how do I orchestrate it?
|
||||||
|
|
||||||
|
It is very common for a Dagger configuration to integrate with at least one IaC tool.
|
||||||
|
|
||||||
|
## Dagger vs. Build Systems (Make, Maven, Bazel, Npm/Yarn, Docker Build, etc.)
|
||||||
|
|
||||||
|
Dagger is complementary to build systems. Most Dagger configurations involve integrating with at least one specialized build.
|
||||||
|
If several build systems are involved, Dagger helps integrate them into a unified graph.
|
@ -83,7 +83,7 @@ module.exports = {
|
|||||||
type: 'doc',
|
type: 'doc',
|
||||||
id: 'getting-started/index'
|
id: 'getting-started/index'
|
||||||
},
|
},
|
||||||
items: ["getting-started/local-dev", "getting-started/ci-environment"],
|
items: ["getting-started/local-dev", "getting-started/ci-environment", "getting-started/vs"],
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
type: "category",
|
type: "category",
|
||||||
|
Reference in New Issue
Block a user