Deployment

The final step to getting our software into the hands of our users is software distribution. This can take many forms, depending on the environment in which the software needs to operate.

Deployment means consideration of how our software will be used.

1. We sometimes need to install the software into a client’s environment. With complex or specialized software, we may need to install and configure out software system for the customer - often with the expectation that we will configure it to integrate with other systems e.g. we might write medical software that needs to integrate with existing patient data or billing systems.
2. We might sell packaged software, for distribution through a retail chain. e.g. shrink-wrapped games, or firmware updates for the latest carOS. This used to be the most common way to distribute software, but it’s less common compared to other mechanisms due to the easy availability of internet downloads.
3. Sometimes software is distributed from a website. This could include distributing as an installer from your company’s website e.g. Visual Studio Code, or a third-party distributor e.g. SetApp. This is extremely common, especially for OSS, free software or restricted software (e.g. distributed as a demo or with a trial license).
4. Finally, distribution through an online application store is very common. This is typically an attempt by a vendor to provide software distribution as a service. e.g. Steam for distributing games; the Apple App Store or Google Play Store for mobile and desktop applications. Online app stores represent by-far the largest concentration of apps for distribution, but they are somewhat restricted by platform/genre.

Each of these deployment mechanisms will require software to be prepared in a different way. e.g. selling packaged software will require a DVD image that includes digital assets. Selling from an online application store required code signing, going through a code review process with the company that runs the store, and so on.

There are a number of issues to sort out that apply to each of these situations:

• Legal: how do we protect ourselves from unauthorized use, or further redistribution of our software?
• Usability: how do we ensure that users know how to use our software? do we provide documentation or training?
• Logistical: how do we package our software so that we can distribute and install it successfully? how do we enforce licensing?

See the sections below for each step that you wish to consider.

Release Process

What do we need to do for a software release?

• Update our internal project tracking systems

  • Close the sprint
  • Update and close issues
  • Update our internal documentation e.g. wiki

• Prepare additional materials for the release

  • Release notes
  • User documentation
  • Update build scripts/configuration
  • Build installers

Versioning

• You should version your software, so that every release has a release number and date associated with it.
• The standard convention is a triple, separated by decimals, of the format: major.minor.build. For example, 1.2.3 would be major version 1, minor version 2, build 3.
• • Major signifies a major product release. This is somewhat arbitrary, but typically is released infrequently and includes major features changes or additions. If you charge by release, you would typically charge for every new major version. You might release a new major version as frequently as once per year, or as infrequently as once very few years.
  • Minor indicates a minor product release, typically a combination of new minor features, and bug or compatibility fixes. You might release a minor version a few times per year and users would not ordinarily expect to pay for these.
  • Build number is internal build number within a minor release. This is intended to reflect bug fixes only; you typically iterate over builds internally and release the final successful version publically.

Release Chart