.\"
.\"     aegis - project change supervisor
.\"     Copyright (C) 1991-1993, 1999, 2006-2008, 2010, 2012 Peter Miller
.\"
.\"     This program is free software; you can redistribute it and/or modify
.\"     it under the terms of the GNU General Public License as published by
.\"     the Free Software Foundation; either version 3 of the License, or
.\"     (at your option) any later version.
.\"
.\"     This program is distributed in the hope that it will be useful,
.\"     but WITHOUT ANY WARRANTY; without even the implied warranty of
.\"     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
.\"     GNU General Public License for more details.
.\"
.\"     You should have received a copy of the GNU General Public License
.\"     along with this program. If not, see
.\"     <http://www.gnu.org/licenses/>.
.\"
.bp
.nh 2 "When (not) to use Aegis"
.LP
The aegis program is not a silver bullet;
it will not solve all of your problems.
Aegis is suitable for some kinds of projects,
useful for others,
and useless for a few.
.LP
The software development process embodied by Aegis has the following
attributes:
.IP \(bu 2n
Each change set is applied atomically.
.IP \(bu 2n
Each change set must build successfully before it will be accepted.
(This can be trivial, if desired.)
.IP \(bu 2n
Each change set must test successfully before it will be accepted.
(This can be disabled, if desired.)
.IP \(bu 2n
Each change set must pass a peer review before it will be accepted.
(This can be a rubber stamp, if desired.)
.LP
The most difficult thing about Aegis program is that it takes
management buy\[hy]in.
It takes effort to convince many people that the model
used by aegis has benefits,
and you need management backing you up when some person
comes along with a way of developing software "without the extra work"
imposed by the model used by Aegis.
.nh 3 "Building"
.LP
If the source code to your software product doesn't build, it isn't a
product.  However, many software shops commit changes to their repository
without preconditions, and then do a daily build (or worse, weekly).
The problem here is that "pollution" by defective changes is already
\fIin your product\fP before it is detected.  Aegis will not let it be
committed in the first place.
.LP
If your product is entirely composed of scripts or HTML, you can
make the build step completely trivial: "exit 0" is usually used for
this purpose.  Thus, this requirement, while usually highly desirable,
may be avoided if desired.
.nh 3 "Testing"
.LP
There is extra up\[hy]front work: writing tests.
The win is that the tests hang around forever,
catching minor and major slips before they become
embarrassing "features" in a released product.
Prevention is cheaper than cure in this case,
the tests save work down the track.
See the \fItesting\fP chapter for more information.
.nh 3 "Reviewing"
.LP
Code reviews of some sort are normal in most software houses.  Often,
unfortunately, time pressures or other political pressures mean that
code reviews manage not to happen.  Yet the literature repeatedly cites
reviews as one of the most important factors in removing defects before
they reach your code repository.  Aegis requires a code review before
it will commit code into your product; again, the idea is to remove
defects \fIbefore\fP they pollute the product.
.\" vim: set ts=8 sw=4 et :