Thanks for the feedback! We're certainly excited about the recent move towards go's experimental vendoring, I can't say I've had many positive experiences with vendoring myself as it is. The only thing worse than vendoring is not vendoring.
This article is a little outdated in terms of the maintainers endorsements, I'll see if we can update it with that, along with the correction.
Someone tweeted about it shortly after my post when live, Delve does look interesting and a lot more compatible with go in general, but there is significant appeal around being able to use a general debugging tool with go. It's the classic balance of solving a generic problem fairly well vs solving a simple problem very well.
I'll certainly be watching delve closely and using it myself! I am sure I'd have better luck having specific go issues resolved with the delve team since it's a focussed project.
I would not call this an alternative. I think an alternative development workflow involves using packer as well as a number of other top level tools (vagrant for example) and using a number of other languages and DSLs. What you end up with is a VM image, not a container image, so you miss out on some of the container-vm abstractions that make docker and other container technologies so appealing.
We are just starting a beta for our new CI flow which follows the container paradigm very closely. It allows you to build docker compose stacks for your various application images, and run your CI/CD pipeline locally, exactly as it would get run on our hosted platform.
If anyone is interested in joining our beta, just drop me an email: brendan at codeship.com.
There are a lot of really great reasons to use Docker, or any container technology for CI.
First off containers give you a standard interface to a reproducable build. This means you can run something in a container and expect it to behave the same way as something a co-worker runs on their workstation, or something run in the staging or production environments. For CI this is an absolute necessity. Rather than running tests locally, and expecting a CI server closely tracking the production/staging environments to catch issues with different version of the OS or libraries you can expect any build that passes locally to also pass on CI. This cuts down on a lot of potential back and forth. The only shared dependency between CI/local/prod/staging is docker itself.
Another benefit is (almost) complete isolation. This means rather than having different vm images tracking different projects, you can have a single vm image with docker, and have each container running on the vm for any version of any build across your system. From a CI perspective you can abstract most of the complex configuration for your applications into "docker build -t myapp_test ./Dockerfile.test && docker run myapp_test".
Containers use a differential filesystem, so N running containers for an application will take up 1 X the size of the container image + N x the average space of changes made in the running containers on top of that base image. This makes larger images highly space efficient without having to worry about different instances treading on the same folders.
The line between dev and ops blurs a little (devops), but clear responsibilities. Ops becomes responsible for maintaining the docker infrastructure, and dev is responsible for everything inside the container boundary, the container image, installed packages, code compilation, and how the containers interact. A container mantra is "no more 'well it worked on MY machine'". If it works for the dev, it really will work in prod.
Besides this, there a number of benefits around speed, accessibility, debugging, standardization, the list goes on. There are also a ton of great and varied Docker CI solutions out there, from specific Docker based CI like us (codeship), Shippable, Drone, Circleci, as well as standard solutions like jenkins via plugins. Many hosting solutions are supporting docker redeploy hooks for CI purposes. The standardized nature of containers make it trivial for vendors to provide integrations. Even if you don't use docker yourselves, this is certainly a great space to watch.
Technically you can use docker for CI/CD without using it for deploying your app. When you do this you lose some of the benefits listed, but not all. You lose the cohesion between CI/local and prod, but you still gain a whole lot in terms of speed and complexity within your CI infrastructure.
Thomas Shaw did a great talk at Dockercon on introducing Docker to Demonware for CI across a variety of projects. I don't think the video is up yet, but it's well worth a watch if you're thinking of bringing it into your company. In the meantime we wrote a blog post on his talk: http://blog.codeship.com/dockercon-2015-using-docker-to-driv....