25.10. Describe five factors that engineers should take into account during the process of building a release of a large software system.
-
Version Control Consistency
When everyone is working on different portions of an update, or worse, different updates entirely (re; one team bugfixing version 1, another team mostly done with version 2, a third working on starting version 3), the variants on the code base reaches ridiculous levels. Ensuring that all of the things that belong in a release are present, while not accidentally including some code that is not intended for this particular release, requires a significant effort. -
Required Files
Ensuring that all things, such as data files, config files, and updater are all in proper locations, versions, and updated for this particular release. A lot of these semi-documentation files get edited a lot, so care must be taken to ensure that they final build does not accidentally ship with debug mode enabled, for example. -
Timing
Software systems don’t exist in a vacuum, and a single release of an evolving software is a mile marker on the path of this software. Thus, timing is a significant factor in a few ways. Firstly is market-based timing; otherwise describable as ‘how close to release is my competitor?’ This provides an influence on the timeframe for this release, and how agressive it must be. If a competitor is releasing a major update to their software, then your team might want to do likewise, even if it involves including some more experimental features. If it’s quiet out there, perhaps the team has time to make everything perfect. If the competitor is more reliable than you, then your team definitely needs to make everything perfect. -
Changes
In an evolving software, some things are always going to be being made to something. With infinite things that could be next up for improvement or redesign, which changes get approved or denied is one question. When release planning comes into question, though, we arrive at a more significant question; ‘when’? Does this change that redesigns the interface need to be in this release, or two down the line? By balancing the benefits, costs, and timeline, each change must be weighted against the value of having it in this release vs hanging on to it for a future one. Either decision could be the wrong one. -
Build speed
Large softwares have one thing in common; nothing gets done quickly. This factors into the idea of doing builds early, and being careful with what goes into them; taking ones time on a build might be essential, in order to catch bugs before deployment rather than after a user has lost all their data. Alternatively, in a well-managed system that utilizes its frameworks, the build process might be fully automatable; in which case frequent builds with multiple release candidates presents itself as an option when preparing releases. It all comes down to the particulars.