Earlier quoted context omitted.
Thank you I did not know about that. Last time I checked with the sales guy it was not going to happen. I hope they improve their ways, it's a nice tool and I invested a lot of my time into it, but right now GoCD is my default option from now on.
If you have more feedback, I'm happy to connect with one of the PMs or somebody from the Jenkins OSS team. I'm the founder/CEO of Codeship and we got acquired by CloudBees earlier this year. And I want to make sure that Jenkins + all CloudBees products get better :)
Jenkins X: a CI/CD solution for cloud applications on Kubernetes
51–60 of 106 posts
Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes
#52I really don't like the idea of my ci/cd tooling being responsible for provisioning its own k8s cluster....there are a lot of other more mature projects out there for doing this.
Is the idea that the ONLY thing running on this cluster is jenkins-x and review/preview environments or something?
Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes
#53Looks pretty cool. I really don't like the idea of my ci/cd tooling being responsible for provisioning its own k8s cluster....there are a lot of other more mature projects out there for doing this. Is the idea that the ONLY thing running on this cluster is jenkins-x and review/preview environments or something?
The default is to use separate namespaces in kubernetes for each teams developer tools & pipelines, Staging & Production environments (plus Preview Environments). Multiple teams can obviously use the same cluster with different namespaces.
We’d expect ultimately folks may want to use a separate cluster for development & testing to Production. GitOps makes that kind of decoupling pretty easy but we’ve still work to do to automate easily setting up a multi-cluster approach: https://github.com/jenkins-x/jx/issues/479
Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes
#54I 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…
Thanks for using GitLab. If people want to see some raw footage of me using Auto DevOps with Spring after linking it to a Kubernetes cluster please see https://www.youtube.com/watch?v=9D5TwMo-IIw We're considering renaming Auto DevOps to GitOps. What do people think?
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...
Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes
#55Earlier quoted context omitted.
Thanks for using GitLab. If people want to see some raw footage of me using Auto DevOps with Spring after linking it to a Kubernetes cluster please see https://www.youtube.com/watch?v=9D5TwMo-IIw We're considering renaming Auto DevOps to GitOps. What do people think?
Please don't. 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 r…
Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes
#56Interesting annoucement, I'd like it better if there was a clear comparison between the current possibilities offered by Jenkins 2.0 and this version of Jenkins. I'm not huge fan of the demo video, since it doesn't really handle what I can only imagine is a very common use case : I already have a Jenkins 2.0 instance with Jenkinsfiles, how easy would it be to migrate to Jenkins X ? Is it isofunctional with added capa…
Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes
#57Does anyone have Jenkins in production and found it to be reliable and pleasant to use? 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. ho…
Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes
#58This looks like an improvement over what Jenkins 2.0 provides and I wish you guys good luck. I have used and vouched for Jenkins in several companies and some decent sized licenses were bought mainly because of my input. But to me, Cloudbees has done a major dick move making the stages not restartable in Jenkins 2.0, among other things. E.g: Dropping stage view out of nowhere and focusing only in Blue Ocean. I compla…
Thanks for using Jenkins for close to 10 years and sorry to see you move on, but I just want to correct the record here because I don't think the time line of events and your description are accurate.
First, pipeline stages have never been restartable in Jenkins from the beginning of Jenkins Pipeline. It wasn't as if we started with restartable stage and decided to close-source it at one point. From the very beginning, it was a feature we exclusively developed for CloudBees products.
From time to time, we do move some features from products to Jenkins. As somebody later in the thread pointed out, in JENKINS-45455 we are doing just that. Another example of this from early days is the folders feature, which is now used by many.
Any company building enterprise products on top of OSS will likely keep some features in products. And for any given person, only some of those features are likely useful. So while I understand the frustration of "that feature should be in OSS" or "I should be able to just get this one thing for a small price", I don't think there's anything inherently bad about these practices.
As for Pipeline stage view, it is still available today, and IIRC it is also still a part of Jenkins 2 default experience. Now, you are right that, as a contributor of the project, CloudBees is focused on pushing Blue Ocean forward. We think Blue Ocean solves the problem of pipeline result comprehension a lot better, and we'd rather make one solution better as opposed to work on two separate things that solves the same problem simultaneously. That is not to block other people from carrying the pipeline stage view forward, though, if anyone is willing.
I hope that helps,
Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes
#59Earlier quoted context omitted.
If you have more feedback, I'm happy to connect with one of the PMs or somebody from the Jenkins OSS team. I'm the founder/CEO of Codeship and we got acquired by CloudBees earlier this year. And I want to make sure that Jenkins + all CloudBees products get better :)
If you're interested I could provide UX blockers and annoyances from someone who has worked with Jenkins for close to 10 years now. Most of them would be about the UX around declarative pipelines and the frustrations around Configuration as Code with Jenkins.