Add docs for dev and ci/cd workflows

docs/content/en/docs/workflows/ci-cd.md

@@ -4,4 +4,59 @@ linkTitle: "CI/CD with Skaffold"
 weight: 3
 ---
 
-{{< todo 3074>}} ci/cd writeup
+Skaffold offers several sub-commands for its workflows that make it quite flexible when integrating with CI/CD pipelines.
+
+## `skaffold build` | `skaffold deploy`
+
+`skaffold build` will build your project's artifacts, and push the build images to the specified registry. If your project is already configured to run with Skaffold, `skaffold build` can be a very lightweight way of setting up builds for your CI pipeline. Passing the `--file-output` flag to Skaffold build will also write out your built artifacts in JSON format to a file on disk, which can then by passed to `skaffold deploy` later on. This is a great way of "committing" your artifacts when they have reached a state that you're comfortable with, especially for projects with multiple artifacts for multiple services.
+
+Example using the current git state as a unique file ID to "commit" build state:
+
+```code
+➜  getting-started git:(docs) ✗ export STATE=$(git rev-list -1 HEAD --abbrev-commit)
+
+➜  getting-started skaffold build --file-output build-$STATE.json
+Generating tags...
+ - gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db
+Checking cache...
+ - gcr.io/k8s-skaffold/skaffold-example: Found. Tagging
+
+➜  getting-started cat build-$STATE.json
+{"builds":[{"imageName":"gcr.io/k8s-skaffold/skaffold-example","tag":"gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db@sha256:eeffb639f53368c4039b02a4d337bde44e3acc728b309a84353d4857ee95c369"}]}
+
+➜  getting-started git:(docs) ✗ skaffold deploy -a build-$STATE.json
+Tags used in deployment:
+ - gcr.io/k8s-skaffold/skaffold-example -> gcr.io/k8s-skaffold/skaffold-example:v0.41.0-17-g3ad238db@sha256:eeffb639f53368c4039b02a4d337bde44e3acc728b309a84353d4857ee95c369
+Starting deploy...
+ - pod/getting-started configured
+```
+
+## `skaffold render`
+
+Skaffold also has another built-in command, `skaffold render`, that will perform builds on all artifacts in your project, template the newly built image tags into your Kubernetes deployment configuration files (based on your configured deployer), and instead of sending these through the deployment process, print out the final deployment artifacts. This allows your to snapshot your project's builds, but also integrate those builds into your deployment configs to snapshot your deployment as well. This can be very useful when integrating with GitOps based workflows: these templated deployment configurations can be committed to a Git repository as a way to deploy using GitOps.
+
+Example of running `skaffold render` to render Kubernetes manifests, then sending them directly to `kubectl`:
+
+```code
+➜  getting-started skaffold render --output render.txt
+➜  getting-started cat render.txt
+apiVersion: v1
+kind: Pod
+metadata:
+  name: getting-started
+  namespace: default
+spec:
+  containers:
+  - image: gcr.io/k8s-skaffold/skaffold-example:v0.41.0-57-gbee90013@sha256:eeffb639f53368c4039b02a4d337bde44e3acc728b309a84353d4857ee95c369
+    name: getting-started
+
+➜  getting-started cat render.txt | kubectl apply -f -
+pod/getting-started configured
+```
+
+Or, skipping the file writing altogether:
+
+```code
+➜  getting-started skaffold render | kubectl apply -f -
+pod/getting-started configured
+```

docs/content/en/docs/workflows/dev.md

@@ -4,4 +4,44 @@ linkTitle: "Continuous development"
 weight: 1
 ---
 
-{{< todo 3074>}} dev page
+## `skaffold dev`
+
+`skaffold dev` enables continuous local development on an application.
+While in `dev` mode, Skaffold will watch an application's source files, and when it detects changes,
+will rebuild your images (or sync files to your running containers), push any new images, and redeploy the application to your cluster.
+
+`skaffold dev` is considered Skaffold's main mode of operation, as it allows you
+to leverage all of the main features of Skaffold in a continuous way while iterating
+on your application.
+
+
+## Dev loop
+
+When `skaffold dev` is run, Skaffold will first do a full build and deploy of all artifacts specified in the `skaffold.yaml`, identical behavior to `skaffold run`. Upon successful build and deploy, Skaffold will start watching all source file dependencies for all artifacts specified in the project. As changes are made to these source files, Skaffold will rebuild the associated artifacts, and redeploy the new changes to your cluster.
+
+The dev loop will run until the user cancels the Skaffold process with `Ctrl+C`. Upon receiving this signal, Skaffold will clean up all deployed artifacts on the active cluster, meaning that Skaffold won't abandon any Kubernetes resources that it created throughout the lifecycle of the run.
+
+
+## Precedence of Actions
+
+The actions performed by Skaffold during the dev loop have precendence over one another, so that behavior is always predictable. The order of actions is:
+
+1) File Sync
+1) Build
+1) Deploy
+
+
+## File Watcher and Watch Modes
+
+Skaffold computes the dependencies for each artifact based on the builder being used, and the root directory of the artifact. Once all source file dependencies are computed, in `dev` mode, Skaffold will continuously watch these files for changes in the background, and conditionally re-run the loop when changes are detected.
+
+By default, Skaffold uses `fsnotify` to monitor events on the local filesystem. Skaffold also supports a `polling` mode where the filesystem is checked for changes on a configurable interval, or a `manual` mode, where Skaffold waits for user input to check for file changes. These watch modes can be configured through the `--trigger` flag.
+
+
+## Control API
+
+By default, the dev loop will carry out all actions (as needed) each time a file is changed locally, with the exception of operating in `manual` trigger mode. However, individual actions can be gated off by user input through the Control API.
+
+Skaffold exposes an API on a local port for interacting with actions in the dev loop, giving users more fine-grained control over the actions Skaffold performs over the lifecycle of the run. Using the flags `--auto-sync=false`, `--auto-build=false`, and `--auto-deploy=false`, users can tell Skaffold to wait for user input before performing any of these actions, even if the requisite files were changed on the filesystem. By doing so, users can "queue up" changes while they are iterating locally, and then have Skaffold rebuild and redeploy only when asked. This can be very useful when builds are happening more frequently than desired, or when builds or deploys take a long time or are otherwise very costly.
+
+For more documentation, see the [Trigger API Docs]({{< relref "../trigger-api.md" >}}).