Comments on: Continuous Deployment at outbrain

By: Some helpful links to Continuous deployment « hop2croft's software development Blog

Sat, 28 May 2011 18:57:26 +0000

[...] Continuous deployment at outbrain. A massive and very detailed example of continuous deployment. [...]

By: Ran Tavory

Ran Tavory — Mon, 16 May 2011 09:23:22 +0000

Actually I have improved on that already (the size of the RPM is now 2M on average). But I’ll look at presto, sounds interesting

By: Changming Sun

Changming Sun — Mon, 16 May 2011 09:17:56 +0000

“They are about 70M, and their size is mostly influenced by the large number of 3rd party jar files embedded in the WAR.”

you should try the presto plugin for yum.

By: Desde la Integración continua hasta Despligues continuos en Software | Lycka Bonita

Mon, 25 Apr 2011 08:08:16 +0000

[...] de la interesante entrada Continuous Deployment at outbrain en PrettyPrintMe, larga entrada que puede ser una buena alternativa si no escuchas la presentación [...]

By: Jamie

Jamie — Sat, 05 Feb 2011 04:38:09 +0000

Great post!

My team has recently decided that monthly big-ball-of-mud releases weren’t working for us and developed a simple CD pipeline using TeamCity, shell scripts, and maven. It makes development pure joy.

We’re now applying this approach to other projects and gradually winning hearts over to this process. I expect that once developers get used to having their code automatically tested and deployed, they will never go back to manual releases. This is an awesome paradigm shift!

-Jamie

By: Ran Tavory

Ran Tavory — Fri, 04 Feb 2011 07:01:27 +0000

Although I’m personally a big fan of git, from the perspective of CD SVN was not limiting.
We use trunk and trunk only so there’s no need to merge commits to a branch. When we worked in batch-mode then we did use release branches but now with CD there are no branches at all, everything goes straight to trunk and trunk is always stable and ready to go live. It sounds frightening at the beginning but if you have good test coverage then it actually becomes much more convenient and even safer than branching and merging (admit it – merging in SVN isn’t fun…).
The post commit hook simply looks at the commit message and if it has a #deploy then it pings the CI server to start a release build. If you want to look at the code, it’s published here https://gist.github.com/810823

Good luck.

By: Jim Frantzen

Jim Frantzen — Fri, 04 Feb 2011 00:44:21 +0000

Thanks, great post.

My shop is just starting to figure out how to get from our batch style dev to where you guys are today.

Do you find using SVN limits where you can go with CD?

I’m interested in how your post-commit process extracts commit messages that contain #deploy. Are you picking out revisions (since the last deploy) and then merging changesets to a deployment branch?

“When the commit is done a subversion post-commit hook is run and extracts the #to and #deploy parameters from the commit. It discards all commits that don’t have #deploy and those that do have #deploy are sent to the CI server”

By: Ran Tavory

Ran Tavory — Sun, 30 Jan 2011 07:01:33 +0000

@Joe glu was open sourced by linkedin at https://github.com/linkedin/glu

GluFeeder is a component we wrote at outbrain and was not open sourced. It’s used to gap the bridge b/w what glu understands and knows how to do and some internal build and configuration details we have at outbrain. It was not generic enough to be open sourced.

By: Joe

Joe — Sat, 29 Jan 2011 23:10:56 +0000

I was trying to dig into the component Glu that you mentioned, and GluFeeder, but the only references I find to it are on this blog. Is that something that you developed internally at your company, or something available externally that I’m just having trouble finding?

By: Yan Pujante

Yan Pujante — Sat, 29 Jan 2011 16:13:18 +0000

Thanks a lot for the explanation about Control Tier. I think I understand now. And I love your comment: ‘chef+glu are a pure joy’

Yan