
Ask HN: How do you organise your deployment code? - verletx64
I&#x27;ve seen people put the CI code in another folder in the same repository, and include some build scripts in the main codebase folder.<p>I&#x27;ve seen people really separate out their repositories.<p>I&#x27;ve seen absolute messes.<p>How do you prefer to organise your deployment code?
======
verletx64
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.

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

~~~
smt88
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.

~~~
dozzie
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).

~~~
smt88
> _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!

