kjuulh/dagger
Archived
1
0
Fork 0
Code Issues 1 Pull Requests 1 Projects Releases Wiki Activity

Docs: rewrite intro and "vs" to match landing page

Browse Source 
Signed-off-by: Solomon Hykes <solomon@dagger.io>
This commit is contained in:
Solomon Hykes 2021-12-07 21:39:49 +00:00 committed by Solomon Hykes
parent 4dd72b78a1
commit 79f86227f3
2 changed files with 31 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
docs/introduction/1002-vs.md
View File

@ -4,40 +4,43 @@ slug: /1002/vs/
# 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.)
_Summary: Dagger can be used with or without a PaaS system._
Dagger is not a PaaS, but you can use it to add PaaS-like features to your CICD pipelines:
A PaaS system is a complete platform for deploying and running certain types of applications.
* A simple deployment abstraction for the developer
* A catalog of possible customizations, managed by the platform team
* On-demand staging or development environments
- The benefit of using a PaaS system is convenience: developers don't have to worry about the many details of deployment: everything just works.
- The drawback of using a PaaS system is lack of flexibility: only certain types of applications are supported.
As an application grows, it is almost certain to outgrow the capabilities of a PaaS system, leaving no choice but to look for alternatives. A good strategy is to choose the right platform for each component. Some components continue to run on a PaaS system; others run on specialized infrastructure. This strategy can be implemented with Dagger: each component gets its own deployment plan expressed as code, and Dagger glues it all together into a single workflow.
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
_Summary: Dagger can augment your deploy scripts, and later help you simplify or even remove them._
Most applications have a custom deploy script that usually gets the job done, but is painful to change and troubleshoot.
Most applications don't fit entirely in any major PaaS system. Instead they are deployed by a patchwork of tools, usually glued together by an artisanal script.
Using Dagger, you have two options:
A deploy script may be written in virtually any scripting language. The most commonly used languages include Bash, Powershell, Make, Python, Ruby, Javascript... As well as a plethora of niche specialized languages.
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.
Most teams are unhappy with their deploy script. They are high maintenance, tend to break at the worst possible time, and are less convenient to use than a PaaS. But when you need control of your stack, what other choice is there?
## Dagger vs. Infrastructure as Code (Terraform, Pulumi, Cloudformation, CDK)
Dagger can either replace artisanal deploy scripts altogether, or augment them by incorporating them into a more standardized deployment system. This is a good strategy for teams which already have scripts and want to improve their deployment gradually, without the disruption of a "big bang" rewrite.
Dagger is the perfect complement to an IaC tool.
## Dagger vs. CI (Github Actions, Gitlab, CircleCI, Jenkins, etc.)
* 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 to I orchestrate it?
_Summary: Dagger can be used with or without a CI system._
It is very common for a Dagger configuration to integrate with at least one IaC tool.
Dagger is not a replacement for a CI system. It can be used to deploy applications directly from the terminal,
or automatically as part of a CI script.
## Dagger vs. Build Systems (Make, Maven, Bazel, Npm/Yarn, Docker Build, etc.)
## Dagger vs. Build Systems (Make, Maven, Bazel, Npm/Yarn, etc.)
_Summary: Dagger can be used with or without a build system._
Most deployment workflows involve building: the process of producing executable artifacts from source code. Build systems are highly specific to the type of application, the programming language in use, etc.
Dagger can integrate any build system into an overall deployment workflow. If a Dagger module is not already available for a particular build system, a custom module can easily be written, and perhaps even contributed to the open-source catalog for everyone else to use.
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.

31
docs/introduction/what_is.md
View File

@ -4,32 +4,13 @@ slug: /
# What is Dagger?
Dagger is a universal deployment engine. Write your deployment logic once, run it securely from anywhere.
Dagger is a portable devkit for CICD. It helps you develop powerful CICD pipelines that can run anwyhere.
Key features:
* Escape YAML hell. Thanks to the Cue language, writing configuration is as fun and productive as writing code.
* A powerful declarative execution engine to automate even the most complex and custom logic
* Static type checking so you can catch configuration errors before running that huge deployment
* Built-in caching and parallelism for maximum scale and performance
* An ecosystem of reusable packages to save you time and share your expertise with the community
* Avoid CI lock-in: the same Dagger configuration can be used in any CI, or with no CI at all
* Rapid local development: test and run everything locally, in seconds.
* Deploy from CI or the laptop: no more duplicating your CI config in a Makefile just so you can perform a task locally.
* Native support for encrypted secrets
* Just-in-time artifacts: fetch, transform and produce any artifact on the fly: source repositories, container images, binaries, database exports, ML models...
Using Dagger, teams with different deployment workflows can more easily collaborate and deploy each other's software,
without being forced to change their tools.
Typical use cases:
* On-demand staging environments for reviewing code changes
* Manage CICD across multiple repositories and CI runners, with one unified configuration
* Iterate on infrastructure without disrupting development teams
* Lock down access to the production cluster so that only authorized configurations are applied
* Common ground between the PaaS, Kubernetes and Serverless siloes.
* On-demand integration environments for testing complex changes spanning several teams
* Choose from a wide catalog of reusable actions, or create your own in your favorite programming language.
* Tie it all together with [CUE](https://cuelang.org), the next-generation declarative language invented at Google. No more YAML hell!
* Unify dev and CI. The same Dagger pipeline can run on your dev machine or in CI. All you need is a Docker-compatible runtime.
* Avoid CI lock-in. Dagger runs natively on Github Actions, Gitlab, CircleCI, Jenkins, AWS Codebuild, Tekton, and more.
* Test and debug your pipelines locally; catch configuration errors in seconds with static type checking.
![Dagger_Website_Ship](https://user-images.githubusercontent.com/216487/122216381-328a3500-ce61-11eb-907f-d2b6f66b3b10.png)