[OPEN-ILS-DEV] Planning for Evergreen development, post 2.0

[Dan Scott]

On Fri, Jan 07, 2011 at 01:01:50PM -0500, Dan Scott wrote:
> A few developer meetings ago
> (http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-01-04)
> , I threw out a couple of ideas about Evergreen development tasks that I
> thought we should start considering once 2.0 wraps up. We decided to
> brainstorm these on the mailing list, and so here's an email to kick
> things off. I'd suggest that if you want to discuss one of the ideas in
> depth, that you reply and change the subject to create a new thread; if
> you want to add another idea, just reply to this message and keep it in
> the thread (then detailed responses to those could go in new threads).
> And of course we have limited resources, so there's no way we'll be able
> to tackle everything, and at some point we'll have to prioritize. At
> this point, though, I would suggest we brainstorm as much as possible
> and then worry about reality :)
 
Something closer to reality than I would have expected a few days ago is
the possible return of continuous integration to Evergreen. I spent a
chunk of today putting together a CI server on a Debian Squeeze VM using
the buildbot project code from http://buildbot.net and have a master
definition for OpenSRF that the build slave uses to follow commits and
automatically configure, compile, run unit tests, and run checks (like
pylint) against the updated source. It generates informative web pages
out of the box (they're not particularly pretty, but they are
template-based and can be customized if someone is so inclined) and can
send email to devs when the build is broken. Oh, and of course it can
create downloadable tarballs to support incremental builds.

buildbot supports tracking and testing multiple branches and projects,
so we could configure it to build and test with OpenSRF trunk, 2.0 and
1.6, and Evergreen trunk, 2.0, and 1.6. It also supports multiple build
slaves on different platforms, so if we wanted to get a build farm going
we could test on exotic distributions - even Windows (good for
automating staff client packaging, if Thomas hadn't already provided us
with a Linux-based approach for post-2.0!).

The value that the project gets out of a CI server can be increased if
we can lean on the CI server to do the work that is otherwise
human-powered. The more unit tests we have to run for coverage of our
code base, the stronger the safety net we have for refactoring code. If
we automate the packaging process, we will reduce our "bus factor"
considerably and maybe be able to let Mike go on holiday again some
time. We could test the creation of the database schema so that we know
that it is indeed building successfully on a completely clean database;
we could run the i18n test scripts to check for known problems on that
front; we could run pylint and perlcritic and rats to flag potential
problems... lots of possibilities.

So... shall we?