Releasing an internal build

From Shadowrun: Awakened

In order to develop Shadowrun Awakened incrementally and simultaneously shield Quality Assurance from the code-churn of active development, we follow a policy of internal software release. This is a process where development publishes code to QA, presenting them with mostly working product that can they be analyzed and iterated upon.

In Development

For most of its life, software is being worked on by developers. It exists in a state of flux while components are created, modified, or sometimes removed. When software is in a state of pure change, it is difficult test since features can change day-to-day. Also, any evaluation of the software from a usability standpoint is impossible as a design may be only partially implemented.

While the software is "in development", is worked on in the "SRA_Development" branch of the SVN repository. Active developers commit changes directly or through submitting patches to active developers. While it is possible for a prospective tester to download, build, and run this code, it is not generally a good idea to write bugs against it.

Feature Complete

Once a significant area of functionality is implemented, a lead developer may designate it as "feature complete". This is to say that the features are existent in the software, personally tested by them, and robustly commented and documented. This includes any refactoring for enhancing maintainability. At this point, the software is ready to be passed on to QA.

Feature completeness may exist in only a small area of the total software, it is sometimes the goal of feature completeness to test in the unit and integration scale. As long as there are no outstanding issues at the system scale of the software that would preclude reliable black-box testing, then it should be possible to make an internal release after creating only a small subset of features planned for the horizon of the project.

It is also possible for an internal release to be motivated by bug fixes alone, especially around crunch time. In this case, the same procedure is followed.

Internal Release

When a lead developer designates an area as "feature complete", a merge is performed from the SRA_Development branch to the SRA_Beta branch. The SRA_Beta branch is a snapshot of in development software that is stable enough for internal testing, but not external release. Creating a separate snapshot for QA has a few advantages:

• Developers can continue modifying code in their own branch without perturbing QA
• If an issue is found, a developer can directly debug the code given to QA and the latest development code separately
• If an issue is unreproducible in the latest development code, we can identify changes that modified the behavior

In addition to taking a snapshot of the code, various binaries will be produced for black box testing. These binaries will be distributable to non-coder testers (such as gameplay testers).

Once the snapshot is taken and the binaries are released, an announcement will be made on the boards. Information regarding specific testing tasks, corresponding documentation, and bug fixes since last release will be disseminated as needed.

Testers may then sync SRA_Beta and/or run the binaries. Design issues, potential changes, and plain old Bugs will then be turned in against the internal release. Development will then use the new information to make changes, all of which will be released to QA sometime later once development is done implementing them (and performing their personal testing).

Crunch Time

The frequency of internal releases will naturally increase as we approach time for an external release. In this time of "crunch", QA may be tempted to peek directly into SRA_Development. While it is always on each developer to ensure individual check-ins do not violate the integrity of the software (especially during crunch time), testing in SRA_Development at any time is not a good idea.