Merge branch 'release-management-strat' into 'master'

  stage: codegen

  script:

    - ./scan-images.sh

  allow_failure: true

  artifacts:

    when: always

    paths:

      - docs/secu/

    # reports:

    #   container_scanning: "reports/trivy-*.gitlab.json"

  rules:

    # on prod branch: auto & allow failure

    - if: '$CI_COMMIT_REF_NAME =~ $PROD_REF'

      allow_failure: true

    # on non-prod branch: manual

    - if: '$CI_COMMIT_REF_NAME'

      when: manual

      allow_failure: true

check-links:

  image:

* 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 upgrades.

* 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. 

* TBC supports (and encourages) production-grade [Git branching models](./understand.md#git-branching-models) 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).