I'm trying Gitlab atm, it's great to see something simpler than Jenkins to do CI/CD.
Glad to hear that. We'd love to hear your feedback about GitLab CI/CD.
Shifting Gears
11–20 of 123 posts
Re: Shifting Gears
#12I love working with Jenkins - I know it is a pain to keep up to date but for me it has become a way as a sole or small team syseng to manage all kinds of stuff. "Jenkins-Ansible-Github" where you have a Jenkinsfile sitting in the git repo you are bulding/ deploying etc., has been a pretty good set of tools to manage heterogeneous environments.
Agreed. Now if only they could generalize Configuration as Code: https://github.com/jenkinsci/configuration-as-code-plugin. It's the missing piece.
Re: Shifting Gears
#13Jenkins's biggest strength is also its biggest weakness: plugins. Any development shop that has been using Jenkins for a while is using at least a bunch of plugins. Plugins are not stable, they break every now and then. They require constant update with new Jenkins versions. They get abandoned by their creators (hell, many plugins still don't support pipeline). It's a fundamental issue with how Jenkins is set up that…
Agree. The same happened with Eclipse IDE
And Firefox to some extent, except they actually fixed it by requiring all addons to be reimplemented. Lesser of two evils and all that
Re: Shifting Gears
#14I'm surprised that I haven't seen more of this announcement in my media streams. I'm not a big fan of Jenkins, I find it overly complex and a Swiss army knife.
When you can do anything, you often end up with poor implementations (IMO). If the tools you have are restrictive but useful enough, I find it easier to adopt my workflow for the tools instead of demanding that my complex workflow fit into this one tool.
Re: Shifting Gears
#15Nice to know there is a plan and it's refreshing to see that they can understand most of the problems from the customer perspective now.
I hope they address the constant shifts in focus with this plan and Jenkins can secure it's market spot, it really deserves it from a historical point of view in the least. It should not be a Nokia or a Xerox, it's better than that and has been a major tool for the industry.
The whole CRD is a great way to move forward, but Argo is looking great right now and it's way ahead, if they manage to finish it soon and make it production ready it will be hard to beat it.
The problem is that every segment has it's player now and there are some big ones, GiLab, GoCD, Spinnaker, Concourse... So many tools and the difference is that most of them have more focus than Jenkins does, they also have newer code and more speed, each has a niche but Jenkins has the market share, it will be an interesting match.
Jenkins is fighting a bit of a uphill battle but with a huge army.
I hope they keep it simple, focus in being the best in one or 2 things and then scale to other areas, that is my 2 cents.
Re: Shifting Gears
#16I'm surprised they have such a good understanding of Jenkins' shortcomings. It's a good first step in fixing them. Although to be fair, this has been coming a long time as the post says; but having Cloudbees' CTO publicly acknowledging those is even better.
Re: Shifting Gears
#17I'm trying Gitlab atm, it's great to see something simpler than Jenkins to do CI/CD.
Glad to hear that. We'd love to hear your feedback about GitLab CI/CD.
I've been working with gitlab CI for the last year. Here are some of my feedbacks:
- 6 months ago we seriously considered moving away because it was really unstable (even when running on private runners) but now its a lot smoother
- with private runners you can have a very powerful CI without having to manage a master (as Jenkins) for a fraction of the costs (runner with docker-machine on spot instances)
- beware that if your CI flow is more complex than just a simple pipeline to build and deploy your project (we have a project for our code, that then trigger a project for end-to-end tests, that then trigger a deploy to our env) you will need to do a lot of boilerplate code (you will need to manually manage artifacts if they need to be shared between jobs)
- variables from a triggered pipeline should be available through the API and made more visible in the UI
- we do not use kubernetes so eveything CD is off the plate for us (environment and monitoring tab are useless)
- DO NOT USE THE BUILT IN CACHE, it's super slow and will fail unexpectedly (simply do cp to s3 and it will never fail)
- IF YOU USE THE BUILT IN CACHE, parallelism will be hard (you cannot populate part of the cache from a job, another part from another job and in the next step use the result of both cache)
- triggers are weird, its a curl to an API endpoint but it does not use the normal auth mechanism and it will answer with a useless json (please add the project id, variables etc to the result of the trigger it's a must have for anyone that needs to parse the output)
- the gitlab API is top notch except on the CI part...
- be ready to restart some jobs 2-3 times if gitlab is deploying a new version ;)
- be ready to have some random errors that can be fixed by a retry
- it will seem a good idea to run gitlab-runner on every laptop of your team to reduce cost. DO NOT DO THAT, if you are more than 2 in your team the guy in charge of making the CI run (me) will make you restart you docker, delete a specific image, restart gitlab-runner, etc... invest 1 day to setup the docker machine on spot
- please show in some way when a job triggered another one (maybe a section in the YML, or even better check make us populate an env var with a link to the triggered pipeline or anything)
- design your pipeline so that if a part fails you can restart it without breaking everything (I'm looking at you terraform)
This list seem really long but, I have worked with Jenkins and even if more stable the steady improvements and addition to gitlab CI still make it my first choice for my needs.
Re: Shifting Gears
#18I think this is too much too late for Jenkins.
I can't speak for other countries but in London a lot of companies are now using Gitlab or Circle CI.
I migrated all my builds (12 projects) to Gitlab CI. After figuring out the first CI pipeline using DockerInDocker, it was easy to then setup the remaining pipelines.
Self hosting Gitlab was perfect for our needs (private docker registry). I use Gitlab for personal use too.
I wonder if they will get rid of Ruby in the future though and go Java to make it more performant, as it does slow down sometimes.
The Jenkins box is still running though, more out of sentimental value :)
Re: Shifting Gears
#19Earlier quoted context omitted.
Glad to hear that. We'd love to hear your feedback about GitLab CI/CD.
I've been working with gitlab CI for the last year. Here are some of my feedbacks: - 6 months ago we seriously considered moving away because it was really unstable (even when running on private runners) but now its a lot smoother - with private runners you can have a very powerful CI without having to manage a master (as Jenkins) for a fraction of the costs (runner with docker-machine on spot instances) - beware tha…
> it will seem a good idea to run gitlab-runner on every laptop of your team to reduce cost.
Will it?!
Re: Shifting Gears
#20I'm surprised they have such a good understanding of Jenkins' shortcomings. It's a good first step in fixing them. Although to be fair, this has been coming a long time as the post says; but having Cloudbees' CTO publicly acknowledging those is even better.
He's not only Cloudbees CTO, he's the original developer and architect.
And before someone lambasts him for the Jenkins architecture, Jenkins/Hudson was created in 2005, when things were a lot different, and Jenkins managed to create an entire subgenre of software and lead it to the current day. Jenkins hasn't aged gracefully but how many software products from any category have even survived 5 or 10 years? :)