Beyond CI/CD: GitLab's DevOps Vision (2017)

Post by vorg » Mon, Mar 19, 2018, 10:18 PM UTC

bpicolo wrote: post #33

Already__Taken wrote: post #13

Earlier quoted context omitted.

Can't you put the gitlab runner on whatever you want and set up CI environments to the runner?

The issue is that the configuration format makes complex jobs difficult to define. It's good for the simple case, but versus e.g. a Jenkinsfile[0] where you get a complete groovy DSL that can interact with it's environment across tasks, pipeline, branch, etc with ease it's rough. Having fine-grained control becomes important. [0] https://jenkins.io/doc/book/pipeline/jenkinsfile/

> a Jenkinsfile[0] where you get a complete groovy DSL

Apache Groovy isn't "complete" as shipped with Jenkins. It's collections API is deliberately crippled so it doesn't work.

Post by pas » Mon, Mar 19, 2018, 10:54 PM UTC

tazjin wrote: post #46

akvadrako wrote: post #41

Earlier quoted context omitted.

The tag points to the current version of your docker image, which contains the current configuration, except secrets which you don't want in a repo. Older deployments point to the older docker images which contain the older versions. Still don't see any advantage to justify the additional complexity in your system.

We have more than one service, more than one environment, and auditability requirements (due to being a financial institution). I find it more complex to try and keep track of remote state modifications than to have a single source of truth, but whatever floats your boat ;-)

You can export k8s state as JSON/YAML and put that into a git repo if you want.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)