Live data from Hacker News

Jenkins X: a CI/CD solution for cloud applications on Kubernetes

jenkins.io

51–60 of 106 posts

Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes

#51
post #36

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 :)

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.

Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes

#52
Looks 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?

Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes

#53
post #52

Looks 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?

Thanks! You are free to use any kubernetes cluster and install Jenkins X there: http://jenkins-x.io/getting-started/install-on-cluster/

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

#54
post #50
post #21

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…

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 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

#55
post #54
post #50

Earlier 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…

Thanks for the feedback! When you say promotion happens via environment repos do you mean via feature branches or really via repos?

Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes

#56
post #42

Interesting 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…

I'm leery of projects whose goal is make bootstrapping easier. Bootstrapping projects has generally gotten easier and easier and was never a real bottleneck. Projects spend 99% of their lifetime in development and maintenance so those are the parts that need the most help.

Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes

#57

Does 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…

Pleasant? Never. I absolutely hate every time I have to launch a webpage to dig around and find out why my build failed. Automating jobs is a nightmare. I can cURL a request to kick off a build and do you know what it returns? NOTHING a 201 response with NO information to link to the build in progress. Oh there's a JSON API to see running jobs, but without some sort of ID, it's useless. Scripting is in Groovy. Want to use another language? Too bad! "It was hard enough to get Groovy" is the response from the team. If I'm forced to use a web interface, does it still have to look like it was designed by a team of Java devs from 2008? The only thing that's changed is the Hudson to Jenkins clipart. Yes, I'm ranting.

Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes

#58
post #34

This 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…

Creator of Jenkins & CTO of CloudBees here.

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

#59
post #51

Earlier 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.

That would be awesome. Could you email me at mo@codeship.com? I will connect you with the right person.

Re: Jenkins X: a CI/CD solution for cloud applications on Kubernetes

#60
When I started using Travis I immediately got a fan of it. Not having worked with Jenkins before, when I first tried it (pre-blue ocean), I was shocked by the unnecessary complexity. Since then, I've settled with a self-hosted drone.io for private projects, it offers a very similar experience to Travis, while I don't feel like I'm lacking anything compared to Jenkins.
Post reply on HN