Ask HN: How do you organise your deployment code?
2 comments
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.
I don't love it, but an entire separate repository seems the wrong way to go about things.
A separate branch with debianization, so I can actually build DEB packages out
of the code.
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.
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.
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).
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).
> but then you're using Ansible, which is locks your deployment procedure
The good thing about Ansible is that it took about 5 min to find a pre-written YAML file, and it's easy to understand it and translate it into something else if necessary.
I have yet to find a solution that eliminates all vendor lock-in unfortunately. It'd be great if there were an open-source format for describing infrastructure, and it had lots of compatible build tools...
I'm going to try out the DEB option, though! Thanks!
The good thing about Ansible is that it took about 5 min to find a pre-written YAML file, and it's easy to understand it and translate it into something else if necessary.
I have yet to find a solution that eliminates all vendor lock-in unfortunately. It'd be great if there were an open-source format for describing infrastructure, and it had lots of compatible build tools...
I'm going to try out the DEB option, though! Thanks!
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
Hm the separate branch thing ain't a bad idea..
I've seen people really separate out their repositories.
I've seen absolute messes.
How do you prefer to organise your deployment code?