We recently deployed AD in our self hosted gitlab instance and combined the SAST container checks with our production policies, it’s been rock solid.
Add to this the fact we are able to manage all the production policies via the pipeline API’s and AD templates, the whole Jenkinsfiles deal seems far less scalable and difficult.
I have no affiliation with gitlab.
Or the automated feedback on releases to all your issues as they move through Environments: http://jenkins-x.io/about/features/#feedback
Or the automatic publishing of Helm charts to the bundled Monocular for all versions of your apps for your colleagues to easily be able to run via helm?
Or that it works great with GitHub, GitHub Enterprise & JIRA and has awesome integration with Skaffold?
Or easy setup a kubernetes cluster with Jenkins X on any public cloud in one command: http://jenkins-x.io/getting-started/create-cluster/
I am using gitlab, though we quickly grew beyond auto devops.
Your definition of auto devops is different than gitops. Gitops is the practice of using commits and pull requests to execute change and do releases. Weave uses it to mean git as the source of truth. https://www.weave.works/blog/gitops-operations-by-pull-reque... Kelsey Hightower talked about it and and has demoed the workflow of using pull requests to initiate promotion and deployments.
Gitlab's auto devops does not seem to tackle promotion via environment repos, so in my understanding does not fit gitops and would be confusing to call it such.
Edit: Kelsey Hightower's kubeconf talk - https://www.youtube.com/watch?v=07jq-5VbBVQ
And a better writeup on weave's site -https://www.weave.works/blog/gitops-high-velocity-cicd-for-k...
Don't get me wrong, I think auto devops is a good thing, but it's most certainly not gitops.
To add to that, GitOps as defined by Weaveworks and Kelsey Hightower is a technology agnostic approach.