Software release

At the end of each iteration, you should be producing a software release, and publishing it on your project page.

What is a software release?

A software release is process where you halt development, and generate an installable version of your product that contains specific, known and tested functionality. Typically this is done so that you can provide them with a working copy of your software either for further testing, or actual use/deployment.

Before producing a software release:

• You have completed all of the features that you intended to complete OR you are at the end of your interation.
• Your code is fully committed, and merged on a release branch.
• All tests should be passing correctly on that release branch.

A software release should include:

• An installable version of your software.
• Release notes detailing what has changed in this release.

A software release should ALWAYS be well-tested and high-quality, and something that you could give to a user to install and test.

Why do we produce these releases?

There’s multiple reasons why we do this.

Iterative development

We also produce software releases as a way of being honest with ourselves. It forces us to do mundane but important tasks like:

• Keeping issues in GitLab up-to-date.
• Merging features and code changes more frequently than we might otherwise do. Frequent changes help us avoid code drift (and costly/complex merges later).
• Ensuring that our product can actually be installed in a production environment (vs. a “it works in the IDE!” mentality).
• Checking in with our customers! When used alongside regular demos, they are an important part of our feedback cycle.

Without software releasess (i.e. “lines in the sand”) it’s easy to let these things slide until the project becomes impossible to control.

Tracking progress towards a final release

In Agile development, your goal is to get to a point where every release is a potential candidate release for a customer to deploy. In other words, it should be high enough quality to actually be used in production, with “real” data. Each software release should produce a product that is closer to a “finished” state.

Having an actual installable release is great for our customers since they can install and test it themselves. It gives them confidence that we’re making progress.

Providing project checkpoints

Once we have more broadly released our product to customers, and people are actually using it, we need to be able to “go back” to prior releases and know definitively what was released.

• e.g., imagine that you release version 1.1 to a customer, and they use it for 3 months before reporting a bug. How do you fix it? The first step is knowing exactly what source code was used, and what the state of your codebase was at that point in time (i.e., v 1.1). Without easily-identifiable releases, you are guessing at what went wrong.

Types of releases

You will often hear about different kinds of releases: alpha, beta and so on. What do we mean by these terms?

From launchdarkly.com:

• Pre-alpha: This stage encompasses all activities that lead up to a major release, including gathering requirements, deciding on the pricing for new features, design, and development.
• Alpha: This is usually where testing and validation of the new code’s behavior begins. Alpha releases are typically tested within the company.
• Beta: Once software passes alpha, it enters the beta stage. Some companies share the beta with prospects and customers as a demo, or make it available for beta testing by a group of users who opt in. This can be a good way to engage your power users or people interested in early access to new features.
• Release candidates: Once any bugs surfaced in beta testing have been addressed, a release candidate is ready to undergo evaluation for stability and suitability as the final version of the software to be released.
• Final release: If no significant bugs emerge when testing the release candidate, you’re ready to release the final version. When and how you do that will depend on your methodology and deployment and release strategies (we’ll dig into those below).

In this course, our development cycles are quite short, so we won’t formally use this terminology. You could consider that everything that we produce is going to be a beta, until the final release.

Producing a release

Here’s what you should do each release.

1. Consolidate code changes.

   Commit all completed code changed and merge back to your release branch (main unless you are told otherwise). Make sure that all automated (unit) tests pass.

2. Assign a version number.

   In your build.gradle.kts, you should change the VERSION to the next valid product version number.

   • We recommend incrementing the second digit for a beta release; your final release would be version 1.0.
   • e.g., Demo 1 is 0.10, Demo 2 is 0.20, …, final release is 1.0. See semantic versioning.

3. Generate a release in GitLab (docs).

   You can start this through Deploy > Release. This will (a) tag your code at this point in time, (b) create an archive of your source code from that tag (note: with proper setup, it’s possible to have GitLab build your project installers, but we’ll do this step manually below).

4. Write release notes.

   Each software release should be documented in a Wiki page, named according to the release number e.g., Version 1.0.0 Release. You should have a section titled Releases in your README.md with a link to this page (and all previous releases).

   The Wiki page for a release needs to include:

   • The release date, which should be the date that the installer was generated. e.g., 12-May-2023
   • The version of this release (which you increment for each release. e.g., 1.1.0 for your first sprint.
   • A bullet list of the major changes that were included in the release, and a link to the issues list in GitLab.

5. Add installer images

   The installer should be a packaged version of your application that a user could use to install your software. If your application consists of multiple components that need to be installed separately (e.g. Android AND desktop) then you need to provide installers for each one.

   Acceptable forms of packaging include:

   • Android: an apk file generated from IntelliJ IDEA or Android Studio that can be side-loaded into a virtual device.
   • Desktop: an exe, dmg or pkg file that installs the application.
   • Service: a Docker image that contains your service, with instructions on how to run it (if you are hosting it in the cloud, then you don’t need a Docker image).

   The last step is to attach these images to the wiki page, so that user can locate them in the wiki and install them directly.

   Important

   When you demo to your TA, you must demo from a software release! You will lose significant marks if you run your code from the IDE or an editor.