Merge branch 'master' into 'master'

Yes.

We have an extensive documentation about [how to use _to be continuous_ in your own self-managed GitLab](self-managed/basic.md).

## How does to-be-continuous compares to GitLab Auto DevOps?

The _to-be-continuous_ (TBC) may appear to be competing and overlapping with the features provided by [GitLab Auto DevOps templates](https://docs.gitlab.com/ee/topics/autodevops/). Here are some notable differences between the two:

* The TBC templates are designed to be **modular** and **composable**, which makes it easy to support a polyglot IT ecosystem (in large organizations for e.g.). Whereas Auto DevOps is more rigid with limited out-of-the-box support for tools and technologies.

* The TBC is **self-contained** and can be **evolved independently** from the GitLab platform itself. Auto DevOps has tightly-coupled dependencies on the GitLab platform.

* Each TBC template is maintained as an individual GitLab project, allowing separate (semantic) **versioning** and GitLab releases. This also allows using tools like [Renovate](https://docs.renovatebot.com/) to automate dependency management, which can be a painful process across large number of client projects. Auto DevOps templates are all developed in a single project, and are not designed to be versioned (can potentially break working functionalities in production).

* TBC supports (and encourages) production-grade [Git workflows](./understand.md#supported-git-workflows) in alignment with the industry best practices of continuous delivery and continuous deployment, while still supporting the ubiquitous Gitflow for those who are not yet mature enough to move to these best practices. TBC takes balanced approach of being opinionated and flexible where it matters, whereas Auto DevOps - much more rigid - can hardly be twisted to fit specific needs. 

* The TBC [adaptive pipelines](./understand.md#adaptive-pipeline) addresses the developer experience for different stages of the development lifecycle. The Auto DevOps takes a single dimensional approach using the branch-pipeline and main pipeline. As a result the Auto DevOps pipelines take longer to run (whichever the development stage) resulting into poor developer experience. Tweaking Auto DevOps to support [Merge Request pipeline](https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html) is far from easy.

* The TBC is **thoroughly documented**: basic notions and philosophy, general usage principles, setup and maintenance for self-managed GitLab, reference documentation for individual templates... GitLab Auto DevOps documentation - limited to the setup instructions - dramatically lacks conceptual information and individual templates documentation.

* The TBC templates have **configurable** inputs with sensible defaults, which covers most customization needs without having to override the YAML file (advanced usage).

* While TBC is addressing both CI & CD, GitLab Auto DevOps is clearly more focussed on the CD part (building a container and deploying it). This is obvious with Maven for instance, where TBC implements many production grade features such as code-coverage integration, SonarQube integration, release plugin, snapshot dependency-check, dependency management, etc... while the Auto DevOps Maven template provides basic build and test with hardcoded Maven version. This is true with almost any build template, but also deployment templates, where TBC systematically integrates leading linters, security checkers and SAST tools having consensus in the community.