Ask HN: How do you organise your deployment code?
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?
7 comments
[ 4.6 ms ] story [ 27.2 ms ] threadI don't love it, but an entire separate repository seems the wrong way to go about things.
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.
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).
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!