Skip to content
GitLab
Next
Closed
Issue created by Sid Sijbrandij@sytsesDeveloper

Auto/Integrated DevOps

Having an integrated product brings emergent benefits. We should provide best practices in an easy and default way, and market these under the Auto DevOps brand. The following features can be part of this:

Some overall goals/priorities:

  • GitLab-controlled (this is not for enterprise admins to set company defaults; we don't want to deal with merge conflicts as we improve Auto DevOps)
  • Same implied .gitlab-ci.yml config as Auto Deploy++
  • Deprecate Auto Deploy button
  • Easy to “grow up” (start from implied .gitlab-ci.yml, edit and commit)
  • No (bad, opaque) "magic"
  • Should do limited, but valuable pipeline if no k8s configured
  • Shouldn’t be horrible if don’t have runners at all

Questions:

  • What about non-web apps? If someone has k8s configured, but the project is not an app, how do we fail gracefully? Build and test might still work, but deploy would be a waste and likely fail, but certainly wouldn't "work".
  • Should we default to using Canaries? (Mark: No)
  • Should we default to deploying to production or staging? (Mark: Production, skip staging)
  • Should we support Openshift? (Mark: No)

Proposal

For first iteration, ship:

The modifications needed are:

Future iterations can then:

Note that Auto CI is a Stretch, since we can ship without it. It's hard to imagine Auto DevOps without CI, but even if all they get is Auto Code Quality, that's some value.

Links

Edited by Mark Pundsack