code packaging

[John J. Lee]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
[...]
> I'm now wondering where this type of thing is best addressed in more
> general terms.  What I usually see happening, in projects I've worked
> on and in others, is that developers get the code working on their own
> computers, using source control tools and (if we're lucky) tests
> developed in parallel with the code, but without much attention to
> final packaging until the very end when the code is about to be
> shipped.
>
> Is this appropriate?  Inappropriate?  Do your projects start using
> serious packaging and distribution tools very early in development,
> before the code is anywhere near usable?  Should they?
>
> I'm involved in something that I wish was that way, mainly because I
> really don't have any way to put a complete installation on my own
> computers; I have to develop my subsystem more or less independently
> of the overall app, then toss stuff over the wall to the more central
> application guys for integration, which gets slow sometimes because
> we're distributed all over.  This is a fairly complex server app that
> depends on a lot of external packages and programs running across
> multiple machines, so I could see the packaging problem being messy.
> It would cause a significant interruption in development to try to
> package things so that the non-central developers could install and
> hack it without a lot of assistance.  But I think it would be
> worthwhile given how much easier it would become to test changes.  We
> do plan to bundle up and release the code sometime (maybe as a Debian
> package) but for now that's deferred until the code is more complete
> and stable.
>
> I'm wondering how other projects go about this.

You can go further: in addition to developing a Debian package (or a
few of them) for your own project, build your OS image using
debootstrap (you'll probably want your own local repository(ies), for
reproducibility).  Then you do your development in a virtual machine
or chroot environment.  That way you develop in the same (or very
similar) environment to the one in which your code will eventually be
deployed (one difference being the use of an version control checkout
rather a .deb install for the code you're actually working on, unless
troubleshooting problems that are somehow tied up with that particular
aspect of deployment).  I've seen this working in a real-world
project.

Of course, you can set up a server that does a complete build-and-test
every night, and a separate continuous integration server that just
does an "svn up" (rather than a full rebuild) every time somebody
checks in, so that test failures can be detected quickly and the
guilty party suitably humiliated :-)


John