I've seen people really separate out their repositories.
I've seen absolute messes.
How do you prefer to organise your deployment code?
I 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!