Releases can be organized in accordance with the development method used by your team.
There are two most common methods:
Working with Waterfall
The Waterfall methodology has been used for years to deliver software projects. With Waterfall, you work on the project in sequential order – first collecting requirements, doing designs, coding, testing, and then moving to production.
Graphically, it looks like this:
Normally, Waterfall projects are shipped as releases – for example, Release 1.0, Release 2.0, Release 3.0, and so on. These release cycles can be months in duration.
If your team is using the Waterfall method, you will define your release and release schedule based on the Waterfall workflow. Usually, it requires creating an iteration for each phase of development within the release cycle. You will also need to keep track of features and requirements.
We suggest creating a Product Backlog folder in Requirements to keep track of future enhancements and requirements.
Below is an example of how you can set up a waterfall environment:
To break down the requirements, you can create agile tasks. Then, create tests to cover each requirement in your cycle.
Working with Agile
With Agile, software development is done in iterations or sprints depending on what Agile methodology you are using. These terms are used to describe a given number of days.
Unlike Waterfall, Agile defines requirements for a smaller set of functionality and implements it quickly. So, the critical functionality is delivered quickly, allowing the client to work on issues with design, without waiting for long periods of time before they can actually use the software to ensure their design assumptions are correct.
In the example below, each sprint is a version of the software that could be moved to production:
|Note:||In this example, Release 1.0 is not achieved until several iterations or sprints are performed.|
If your team is using Agile, we recommend creating a folder for your application or product in Releases, then create a release with iterations for each sprint.
You will also need to keep track of future requirements. For that purpose, we suggest creating a Product Backlog folder in Requirements.
The following is an example of the Releases screen prepared for Agile: