On Tue, 14 Dec 2004, Joe Van Dyk wrote:
> 1) Be able to track third party applications (like Rails)
> 2) Be able to track my work / projects
> 3) Be able to have a "one button deployment system" of a given
project
I''m doing something like this. The basic components:
1. A list of stuff that I need installed on a host before I can bring
my system up. I try to keep this as minimal as possible, so that I can
bring up a new system quickly and also avoid "version hell." Right
now,
it''s basically an OS, cvs, netcat, PostgreSQL, ruby 1.8.2 compiled with
--enable-pthread, and a couple of other little things that are legacy
stuff that I''m trying to get rid of.
2. I keep everything in CVS. Yeah, I should switch to Subversion.
3. I have a directory in my checkouts called "extsrc." This contains
imports of important external software: Apache 2, mod_ruby, libiconv,
libcurl (for php), php4 and a bunch of libraries for it (legacy stuff),
a bunch of ruby libraries (ruby-postgres, test-httpweb, ruby-dbi-call,
activerecord [though in fact I''m not using that at the moment]), etc.
etc. Especially important is that libraries for ruby go in here, rather
than being required on the system, because otherwise you''ll spend ages
tracking down and installing all the necessary pieces.
4. I have a build script under extsrc that goes and builds the
whole thing under separate build directory, installing it under
an install directory. This is essentially repitition of "cd
build; ../extsrc/foo/configure --prefix=../install", but see
http://rafb.net/paste/results/TjuZpj31.html if you really want the gory
details.
5. I then have a test script underneath the project code directory which
will do a rebuild (which does nothing if everything is already built)
and then goes around running the other test scripts. This includes
standard unit testing stuff and web server tests. In both cases, we
first load up the local developer''s database (every developer gets his
own db) with the schema and some test data. In the web server test case,
after that we start up a web server on a random port (well, ports,
since I''m testing multiple servers) and then we run the web tests
against that. The tests are based on test-httpunit and usually follow
the pattern of "put stuff in DB, send http request, check response,
check results in DB." There are also various functional tests for batch
programs and suchlike.
> 4) Have unit tests run when I check stuff in
I don''t bother with this, because I insist that the appropriate tests
run before checkin. Even in a small system like this, my full testing
regime takes a couple of minutes to run, so doing everything on a
checkin would be oppressive. Doing less, well, you still need the
developer to figure out what tests beyond those ones need to be run
anyway, so if you trust her to do that, she''ll do the right thing.
> 5) Any other good ideas?
Just remember: *everything* is code. All those SQL DDL statements? Code
just as much as a Ruby class is. Those rewrite lines in your httpd.conf?
Also code. Make sure that you''re using the same code in test and
production. (I build my httpd.conf files--both test and production--from
templates and code fragments.) Refactor mercilessly. Don''t be afraid to
refactor between languages: if it works better in SQL than Ruby, move it
to SQL. Or vice versa.
cjs
--
Curt Sampson <cjs-gHs2Wiolu3leoWH0uzbU5w@public.gmane.org> +81 90 7737
2974 http://www.NetBSD.org
Make up enjoying your city life...produced by BIC CAMERA