docs.lit

\title{Docs}{docs}

\use-plugin{concourse-docs}

Concourse is a pipeline-based continuous thing-doer.

The word "pipeline" is all the rage in CI these days, so being more specific
about this term is kind of important; Concourse's pipelines are significantly
different from the rest.

\reference{pipelines} are built around \reference{resources}, which represent
all external state, and \reference{jobs}, which interact with them. Concourse
pipelines represent a dependency flow, kind of like distributed
\code{Makefile}s. Pipelines are designed to be self-contained so as to minimize
server-wide configuration. Maximizing portability also mitigates risk, making
it easier for projects to recover from CI disasters.

\reference{resources} like the \resource{git} and \resource{s3} are used to
express source code, dependencies, deployments, and any other external state.
This interface is also used to model more abstract things like scheduled or
interval triggers, via the \resource{time}.

\reference{resource-types} are defined as part of the pipeline itself, making
the pipelines more self-contained and keeping Concourse itself small and
generic without resorting to a complicated plugin system.

\reference{jobs} are sequences of \reference{get-step}{\code{get}},
\reference{put-step}{\code{put}}, and \reference{task-step}{\code{task}} steps
to execute. These \reference{steps}{steps} determine the job's inputs and
outputs. Jobs are designed to be idempotent and loosely coupled, allowing the
pipeline to grow with the project's needs without requiring engineers to keep
too much in their head at a time.

Everything in Concourse runs in a container. Instead of modifying workers to
install build tools, \reference{tasks} describe their own container image
(typically using Docker images via the \resource{registry-image}).

\inline-header{...What?}

Concourse admittedly has a steeper learning curve at first, and depending on
your background it might be a lot to take in. A core goal of this project is
for the curve to flatten out shortly after and result in higher productivity
and less stress over time.

If this all sounds like gobbeldigook, that's OK - you may want to just continue
on, start kicking the tires a bit, and use the above as a quick reference of
the "big picture" as the mental model sets in.


\include-section{./docs/getting-started.lit}
\include-section{./docs/install.lit}
\include-section{./docs/auth.lit}
\include-section{./docs/fly.lit}
\include-section{./docs/config.lit}
\include-section{./docs/pipelines.lit}
\include-section{./docs/vars.lit}
\include-section{./docs/resources.lit}
\include-section{./docs/resource-types.lit}
\include-section{./docs/jobs.lit}
\include-section{./docs/steps.lit}
\include-section{./docs/tasks.lit}
\include-section{./docs/builds.lit}
\include-section{./docs/how-to-guides.lit}
\include-section{./docs/operation.lit}
\include-section{./docs/observation.lit}
\include-section{./docs/internals.lit}

\split-sections
\table-of-contents