Concourse CI Hits 1.0.0

There is a simple 'vagrant up' you can do that allows you to play with Concourse without needing to learn about all the other tooling such as BOSH. It's a great way to get started. Take a look:

Check out VM setup here: http://concourse.ci/vagrant.html Setting up first pipeline here: http://concourse.ci/using-concourse.html

This gets you going with a local Concourse instance that you can experiment with. You're right that it can feel like "turtles all the way down" (quoting @oblio from earlier today), but you do not need to jump in with BOSH right away.

In regards to how to think about 'job' vs 'task', I like to think of 'Job's as a description of what the module is attempting to achieve. For example in the Concourse team's own pipeline[1] you'll see a 'job' named "deploy". 'Task's are on the other hand the individual things that need to happen in order to complete the 'job'.

-- 1. http://ci.concourse.ci/

Sadly, while it's easy to play with the software this way, the 'vagrant up' implementation is missing a bunch of functionality; you don't get any authentication functionality, and you don't get the ability to attach external workers. Also, as of right now, the vagrant build hasn't even been updated to the 1.0 release; it's still limited to version 0.76.0. So you can't play with this new Concourse release using a vagrant box in the first place.

I've had a brief struggle with trying to get the standalone executables to work under Linux, without any success (I'm told that they probably are incompatible with my server's kernel version; note that the documentation does not state what kernel or OS versions are supported). Similarly, I've had a brief look at what it'd take to set up an install using BOSH.. but it looks like that's going to be a massive undertaking.

As a practical matter, if you want to use Concourse for real work, you probably do have to jump in with BOSH right away, since the standalone versions are likely not to work with your VMs, and the vagrant version is missing critical features and hasn't even been updated to the 1.0 release.

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.

And I just want to add.. I really like Concourse. I'd love to use it instead of Jenkins.

But at the moment, I haven't been able to get it to work, apart from in a vagrant box running an old version of the software, which I can't deploy to a real server, and to which I can't attach workers. Which, from a brass-tacks point of view, means that I haven't be able to get it to work at all.

I'd be thrilled if you can make it less painful to install on a proper server. I totally would jump on board in a heartbeat. But I've already spent a couple days trying to make it work, and I just can't afford to throw more of my time at it right now, particularly since I already have a fully functional (albeit somewhat unpleasant and occasionally unreliable) Jenkins install, which only took me 20 minutes to set up and configure.

I'd be very interested in taking another look if and when the whole install process has been streamlined somewhat! There's lots of promise here; I just can't get into it.

I think it's less about putting a list of features in a spreadsheet and checking off boxes, and more about how the tool thinks.

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.