| Congratulations for this release. However as already seen in the case of GoCD, the success of Concourse will depend on how easy it is to convince Jenkins believers. The "vs Jenkins page" needs to be augmented with more information regarding workers, plugins and simple jobs scripts. At the moment that page is not really convincing 1)"Jenkins servers become snowflakes"
All configuration is saved on the disk as XML files. Backing them up or putting them in version control is very easy. Restoring Jenkins servers is very easy. I have done this actually. 2)"Jenkins has no first class support for pipelines"
True. But Jenkins 2.0 will be designed around pipelines, so once it is released this argument will no longer hold. And even today with 1.x not all organizations use pipelines (or are happy with the existing plugins) 3)"Trying to find the build output log for a failed build in Jenkins can be up to 3 clicks from the home page"
That is not really an argument. I get an email when my build fails. As others have mentioned having readers understand new concepts in order to run/use if effectively is problematic. The UI is impressive! Congrats!
I think you should market this more. Basically if the effort required to setup Concourse with 2 workers is bigger then setting up the respective Jenkins setup, Concourse adoption will suffer. It needs to be stressed that for a lot of small/middle sized companies, the build server is just an afterthought. Not everybody has full time people working on setting up pipelines. |
Jenkins can "do" the things that Concourse does, if you assemble enough plugins, click through enough configuration pages and write enough shell scripts. But that's not its native way of thinking.
I agree that lots of Jenkins users will look at Concourse, scratch their head and leave it. But for those who switch, it's really that much better. I think it'll spread largely by word of mouth, especially once it begins to appear in downstream distribution channels.
> It needs to be stressed that for a lot of small/middle sized companies, the build server is just an afterthought. Not everybody has full time people working on setting up pipelines.
I'm in a team of four -- two pairs. We maintain and extend a medium-sized app, central to our revenue, that has some surprisingly complex and legally scary business rules.
These days whenever we're annoyed by something, it's common for us to think "how can we get Concourse to do this for us?", instead of checklists or wiki pages or Just Hoping Somebody Remembers.
I think people tend to set up Jenkins and never touch it again because it's scary to tinker with your CI/CD. Concourse is, despite being configured by flat files and a CLI, much more approachable in this regard.