21–30 of 106 posts
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.
I had to do lots of Jenkins integrations some time ago, and even though I tried to minimize the number of plugins and make things as simple as possible, things would randomly break from time to time or exhibit weird behaviour etc.
I had the impression that Jenkins is deeply conceptually confused about some of its concepts, e.g. how builds are triggered. Also, it is a huge pile of untestable spaghetti code which explains the weird bugs.
I modified an open-source plugin only to find out that it's almost impossible to write meaningful tests for it: you can't even mock Jenkins API without using the darkest Java mock magic. Jenkins classes are just written in an old style that makes testing _really_ hard but probably can't be changed without breaking all of Jenkins.
I tried Jenkinsfile which was only even more unreliable (at the time at least, this was > 1y ago). The whole idea of using groovy, modifying the hell out of it to make it even more weird and surprising and edge-casy just didn't go well for me.
I ended up with generating a _lot_ of very simple jobs for each project and connecting them via triggers instead. It was not very pretty, but it was the most reliable that I could get out of Jenkins.
So the thought of integrating Jenkins deeply into you deployments, talking to Kubernetes and sitting in the middle of a huge pile of complexity (Jenkinsfile, Dockerfile, Helm, ...) and magic "that you don't need to worry about" scares the hell out of me.
But then again, if you want to do CI/CD with Jenkins that's what you might want, right? (I would prefer more simple approaches if forced to use Jenkins, though)
I find this solution compared to the gitlab Auto Devops, frankly, underwhelming. 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…
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/
So we already have a very custom Jenkins setup that builds containers, runs tests and creates test environments out of our pull requests in a k8s namespace. This seems to come with so many things that we already have. We have a few issues with it, like Jenkins suddenly deciding to build & test all branches/PRs in all repos, killing the server. • What is Jenkins X exactly, and how does it relate to Jenkins? Is it just…
* automated CI/CD for your kubernetes based applications using Helm Charts & GitOps to manage promotions (manual or automated)
* a single command to create a kubernetes cluster, install Jenkins X and all the associated software all configured for you OOTB (including Jenkins, Nexus, Monocular etc): http://jenkins-x.io/getting-started/create-cluster/ - ditto for upgrading
* a single command to create new apps or import them via build packs to create docker images, pipelines and helm charts with GitOps promotion: http://jenkins-x.io/developing/create-spring/
* automated release notes + change logs with links to github/JIRA issues etc
* feedback on issues as they move from Staging -> Production
i.e. more automation around CI/CD and kubernetes so you can spend more time focussing on building your apps and less time installing/configuring/managing Jenkins + Pipelines
No TLS on jenkins-x.com, tisk tisk.
If I understand correctly, this creates an environment for each PR. How does it accomplish that exactly? It would require all Kubernetes manifests for resources somewhere in the repo? What if the environment has some stateful dependencies, etc?
You can define what a Preview Environment is in the source code of your application - its just a different Helm chart really. You can of course opt out of Preview Environments completely if you wish. http://jenkins-x.io/about/features/#preview-environments
Though I've personally found them to be super useful - especially if you are working on web consoles - it lets you try out changes visually as part of the Pull Request review process before you merge to master.
If I understand correctly, this creates an environment for each PR. How does it accomplish that exactly? It would require all Kubernetes manifests for resources somewhere in the repo? What if the environment has some stateful dependencies, etc?
e.g. so you could deploy just your front end in a Preview Environment but link it to all the back end services running in the Staging or Production environment. Each team can configure their Preview environment helm chart however they wish really.
Using separate namespaces in kubernetes is a great way to keep software isolated and avoids apps interfering with each other; but at the same time its really handy to be able to link services between namespaces too.
No TLS on jenkins-x.com, tisk tisk.
it's using github pages for the main website i think so i'm not sure if it's possible to setup custom domain + custom ssl cert for it?
Given that Jenkins is pretty popular, you'd think that they'd be able to sort something out with GitHub to get bumped up the list for something along these lines.
There's always the Cloudfare option, but I've never felt that this was an ideal solution when HTTPS should be extremely straightforward for GitHub to set up on their pages.
https://landscape.cncf.io/grouping=landscape&landscape=ci-cd...