Ask HN: How do you organise your deployment code?

https://news.ycombinator.com/item?id=14765857

by verletx64 • 9 years ago

2 7 9 years ago

news.ycombinator.com

I've seen people put the CI code in another folder in the same repository, and include some build scripts in the main codebase folder.

I've seen people really separate out their repositories.

I've seen absolute messes.

How do you prefer to organise your deployment code?

verletx642• 9 years ago

I am not really fond of any of the approaches if I'm honest, but pushed, I will plump for a CI folder in the same repository, with a build script or two swimming around.

I don't love it, but an entire separate repository seems the wrong way to go about things.

dozzie2• 9 years ago

A separate branch with debianization, so I can actually build DEB packages out of the code.

smt882• 9 years ago

Can you point us to a longer explanation of this? I'd be interested in the pros/cons.

I'm wary of deployment solutions that lock into a particular technology. That's why I prefer declarative infrastructure, like what you('re supposed to) get with Ansible.

dozzie2• 9 years ago

You say you're wary of vendor lock in, but then you're using Ansible, which is locks your deployment procedure. Packages actually give you more flexibility.

If you don't put all the build process into debian/rules, but keep a makefile/rakefile/antfile/scons file/setup.py and run appropriate build tool from debianization, you get something that is quite easy to translate to RPM spec or some other packaging format (been there, done that, got a T-shirt).

The benefits from keeping such a package are numerous:

- build procedure (its entry point) is stored in a Well Known Place[tm]

- there is a Good Place[tm] to specify dependencies (including dependencies from OS and other languages!)

- build process is only run once, outside of the deployment phase

- rebuilding a package is repeatable (assuming that you prepare source packages, also for the libraries you use)

- deployment is more repeatable and much faster than with rebuilding libraries for every installation

- DEBs/RPMs are trivial to work with in all the popular (and less popular) tools, like Ansible, SaltStack, CFEngine, Puppet, Chef, or Dockerfile; the reverse is not true

- DEBs/RPMs are easy to upgrade, downgrade, and to deploy an old version of your software in the first place

- DEBs and RPMs give an easy way to verify correctness of their files

- preparing an environment for development for a new team member is much, much easier (`apt-get build-dep mysoftware' and you're pretty much done)

I'm yet to encounter a drawback of this approach, apart maybe from lack of sexiness because of its age (it was invented two decades ago).

verletx642• 9 years ago

Hm the separate branch thing ain't a bad idea..

kkirsche• 9 years ago

In my Python libraries I do a similar thing. I though leverage a makefile with commands for making wheels, RPMs or DEB files so I have flexibility on deployment

Ask HN: How do you organise your deployment code?

Related Stories