Releasing an external build
From Shadowrun: Awakened
The true purpose of Shadowrun Awakened is to create software, assemble assets, and put it out into the world. Every action of each contributor must move toward this goal. This article details exactly what must happen in order for the software to go from being freshly implemented by developers to releasable to the outside world.
In some cases, external releases are for game content and code, sometimes only for one or the other. Given the two separate realms must converge during the deployment process, each will follow this outline of steps, though each group is not guaranteed to synchronize their release cycles.
Contents |
External Release Cycle
External releases for any software organization represent landmarks in their ongoing product objectives. For our game, external releases will be perform after achievement of large intermediate steps between our overall project Milestones. Each cycle adheres to the following steps:
Communication
At the start of each release cycle, the project managers will determine what the minimal requirements necessary for release. An example might be some features from Game Mechanics, some specific bug fixes from the last release, or some specific game assets to be created and added. By setting objectives ahead of time, the project can maximize focus.
Planning
Once the high-level goals are set, the primary duty of project managers is to convert the collective vision of the project into atomic and attainable work items that can be performed by contributors and combined into new product. Often times, the breakdown into work items does not happen all at once. Tasks may be defined and redefined through the building process.
Construction
After creating a cohesive vision for the next release, the developers will begin picking apart the high-level ideas and bringing them down to Earth very quickly by trying to convert them into code. During this time, we create the actual software. Often times, this may mean selecting and integrating a third party library in addition to creating custom code. We must be unafraid to re-evaluate and refactor during this time as most software can always be rewritten better and there's no better time to rewrite than while you still remember how it all works. Again, planning and construction in software often happen together, not because software is developed without a plan, but because plans change so quickly in software.
Internal Releases
As discussed in Releasing an internal build, most of the time, the software is in the hands of developers undergoing modification or extension of its functionality. Once development produces stable, but not comprehensively tested software, QA will be able to analyze and report Bugs on an internal release. All of these internal releases are meant to provide stability leading up to an external release.
Setting a Date
After overcoming most of the large hurtles in implementation and producing some internal releases, the project managers may start to close in on a date for release. As we are a developer-minded group, the date should always be set based on a realistic estimate of when the software can be completed (completing software and releasing software are so rarely the same thing).
Crunch Time
With a real date looming, development should be highly motivated to produce at peak efficiency once the date is set. During this time, release builds may happen periodically and it will be the expectation that no single change will represent a change in architecture, only the completion of feature sets. Crunch time ends once all features are complete.
Code Freeze
Once the minimal requirements have been met for release in all areas, a code freeze will go into effect prohibiting any non-bug-related changes. All available developers should shift into testing. The code freeze will be maintained for a period mandated by the project managers. If a significant change is performed in this time, the duration of the code freeze may be reset. After the software has survived all eyes picking apart every detail, it will be deemed ready for release.
Deployment
In order to deploy our software, we must update the downloadable binaries and any related installers. We must also go live with an updated version of the official Seattle Server. Current player population must be guided through the upgrade, turning them over to the new version. Ideally, a complete world reset should be avoided; however, in early iterations of the product, this is not a guarantee.
In the SVN repository, code changes may resume in SRA_Development. SRA_Beta will be merged into the SRA_Release branch, archiving the code in the latest public release.
Continuing the Cycle
Software is never "done". Products are meant to grow and evolve one release at a time. It is the duty of the supporting organization to do the same. Between releases, the project will foster learning and analysis of the process, performing post mortems on each release and looking for ways to make the process faster, easier, and less painful.
