In my line of work; as a software engineer, I often come across the need to launch system updates. Typically for me, this involves the process of taking one web backed service and launching a major update. The process of such update can be quite complex.
The Plan
As a major update reaches completion an upgrade plan is normally created to plan and manage the changeover process. This plan usually contains:
- Stakeholder management
- informing users of the change to the system so they know what is going on
- managing any concerns stakeholders have with any of the changes (before changes go live)
- A risk analyses and mitigation documentation:
- Documenting what could go wrong, the likely hood of what could go wrong and mitigation and fullback strategies
- Instructions on how the upgrade should be performed – often these instructions are tested in a mock upgraded on similar hardware to ensure that they contain no mistakes.
- Back up instructions for any database data and privacy management stratify to avoid the back up from being compromised or leaked
The Rollout Strategy
There are two major styles of upgrade strategies. The first is where you roll out the new system alongside the old one. The new system is tested by real users and feedback/bugs are addressed before the old system is decommissioned. This strategy is more expensive and time heavy than its alternatives however it tends to be preferable as users are never left without a working system if the new system fails.
Another strategy is turning the old system off and turning the new one on. This strategy is the usually the cheaper of the two but has a higher risk of failure. If the new system doesn't work or has issues then the end users are left with no system or an incomplete/buggy system. This risk, however, is normally managed by a stricter testing before the new system is launched.
An alternative to the above strategy is taking the existing system of line updating the system before the new software online. This process carries a much larger risk because the process to revert the system back to its original state often involves completely resetting the system from scratch (which can often be a long and involved process).
Data Migration
Making changes to a production database is risk heavy process. Before any change are made a back up is typically made so that on the off chance the migration process fails there is a complete back up of all the data. Management of the backup normally involves ensuring that the back up is secured in a way that prevents it from being modified or redistributed. The complexity of these measures largely depends on the sensitivity of the data being backed up or legal requirements surrounding nature of the data (ie medical, personal, records, transactions). In some situations, a database back up may not be part of the strategy due to an automated or pre-existing data backup strategies.
As part of the development process, a set of migration files are created. These files contain code that makes changes to the database schema:
- Table additions/deletions
- Column additions/deletions
- Cullum type modifications
- Column integrity modifications
The second set of files used in the migration process are called seeds. These files contain code that fills in any gaps in data or adds default data required for the update to work. Typically, one would want to avoid having to interpolate seeded data but depending on the updates requirements this may not always be possible.
Zach Radloff lives on the Gold Coast and works as a software engineer for a software development agency.
Zach Radloff is the Press Service International long serving IT young writer from the Gold Coast
