Notes on Software Production
Generally speaking the development process in open source projects is
very organic and depends on the process. I have seen development in
small groups ( 5 people ) to large groups ( 100 people) and have seen
the things that work and the things that don't.
If
Rainbow is to be commercial grade it has to be developed using at least
some of the commercial industry's methods. I think the open source
methodology has some merits so here's what I think is a balanced
approach to Production.
Product Design:The Business
team's responsibility is to understand and analyze the Customer and
conceptualize the best product. There is a great virtue in separating
the product decisions from the implementation. Architects from the
Production team will be involved in helping define the product as far
as what is possible and what isn't.
Product Development:The
Production team's responsibility is to understand the Business team's
decisions and implement them in the best way possible.
SANDBOX: "Sandboxes"Each
developer will have their own sandbox so that they can experiment with
the software in their own environment with free reign.
DEVINT: "Development/Integration"Once
developers have something concrete, Architects will decide whether or
not to integrate the changes into "DEVINT". The Development environment
will be used to do the first level of integration and testing. The
purpose of the DEVINT environment will be to see what all the
developers are working on in one area. Daily builds will be nice, but
we will have to atleast start out with weekly builds. The DEVINT
environment's purpose is to solidify the work of many people into ONE
product. Although "Integration" usually would fall in it's own
environment, we're not that big yet.
TEST: "Testing" After
modules and code sections are approved in development, changes can be
pushed to Testing from development. The "TEST" environment will be used
to do polish up the changes for different types of Testing. There will
need to be System Administrators, Designers, Developers, and end Users
which will be asked to use and try to break the software.
STAGE: "Staging"By
the time code enters the Staging environment, it's pretty much ready to
be shipped. In this environment, everyone from the Business and
Production teams will be required to a series of sanity checks to make
sure that the product is infact ready for release. You can consider
this "Quality Assurance" to a certain degree. Stress Tests might also
be done to see that the software can withstand load.
PROD: "Production"Production
is the real thing. This environment is used to create the publically
available binaries and source. Most end users will be using the code
released from here. The Release Manager's jobs are extremely important.
Their deliverable is what thousands of people will use.
How to handle Releases in their respective Environments.SANDBOX
don't have to have any particular release schedule because they are
"owned" by individual developers. The DEVINT environment should try to
produce a periodic release so that TEST can go through and send back
feedback to DEVINT. Once TEST is satisfied with the product,
STAGE can start tearing it apart for PROD release.
I
really don't have much to comment on source control except that it
should cater to the environments above. All environments should have
their own trunk/tags/branches. The regular releases can go through
trunk, and each periodic build should be tagged. Any Emergency
fixes/patches should be done as a branch and changes should be manually
merged back into trunk.
How to handle multiple products? I will figure this out later. Right now I'm concentrating on getting out a badass 2.0 Rainbow.