To plan a new software development project, we start by creating a software development plan. This plan includes project milestones, necessary resources, dependencies, and risk management.
For existing products, we collect requirements and assign them into product versions. We assign enhancement requirements to “major” release versions, and we assign bug fixes to “minor” (patch) versions, usually in support of a Service Level Agreement (SLA). We resolve critical bugs through hotfixes.
Types of Versions
When planning a new version of an existing software product (for example, Inception CRM), we focus on two main types of version: Major and Minor. A third type of version is the “Hotfix” or emergency release, which focuses on solving a specific critical problem.
Major Version
Major versions focus on major releases and typically introduce new features to a solution. A major version means that the impacts of changes (additions, modifications, deletions of named functions) affect the entire software system, or at least a significant part of it.
While the code level change may be limited to a specific function, the interrelation of functions within the system (especially in terms of hierarchy of objects, from simple to complex) requires us to thoroughly test the whole application.
For Inception CRM, we produce three major versions per year. These major versions introduce many new features and functions and often significantly upgrade previously implemented functions according to new technology standards and practices.
Minor Version
Minor versions focus on small changes to existing features. A minor version means that the impacts of changes affect only the specification function(s) being modified or changed, or have limited extended impact to surrounding or integrally related functions and dependent functions.
When testing changes in a minor version, we test the modified function along with any dependent functions. Since a minor version is usually a patch version, it contains rarely enhancements.
Hotfix
When we assign a hotfix to a developer, the developer resolves the problem immediately, and if necessary, creates a new issue with a requirement for a systematic change that will prevent the problem from reappearing.
The Steps for Planning a Version
Version planning includes:
- agreement on release date of new version
- agreement on priority of issues (critical to low) in regards to their importance to customers/stakeholders and their urgency
- assessment of available capacity (by the Project Manager)
- selection of customer issues based on priority/urgency within the limit of available capacity during the defined time plan
- linking of selected customer issues to version issue
- assignment of customer issues to development team leaders
- assignment of customer issues to individual developers
- informing developers of their assigned duties related to the version (automatic, from Gemini via email)
- evaluation of progress in weekly meetings
- during planning meetings, agreement is reached concerning:
- which customer issues will be included in the version
- time plan for version testing and release (testing performed by different role groups)
- commenting on the progress of each issue linked to the version
- updating of issue status based on progress
- commenting on the issue (may require adjustment of URS/ITS)
We do not include issues that have not been analyzed in any planned version.
Versioning schema
The version number follows Best Practices for .NET Assembly Versioning:
Major Version: Manually incremented for major releases, such as adding many new features to the solution. Major versions are named by years of the version release.
Minor Version: Manually incremented for minor releases, such as introducing small changes to existing features. Minor versions have the order number of the release within a year.
Build Number: Typically incremented automatically as part of every build performed on the Build Server. This allows each build to be tracked and tested.
Revision: Incremented for QFEs (a.k.a. “hotfixes” or patches) to builds released into the Production environment (PROD). This is set to zero for the initial release of any major/minor version of the solution.
For example, major version is 2020.3.0.0, minor version is 2020.3.2.5.
Deployment
Deployment is driven by a project/version Release Plan. The deployment manager knows
- time schedule for testing (i.e. when the version should be deployed to the test environment)
- release date
- environments (customers) to deploy
- applications to deploy
- deployment procedure (how to, including if there is planned downtime of the services)
All applications are built using the automated build procedure that creates deployment packages. D3S uses a tailored in-house deployment application (called ServerDeployer) that enables automatic deployment (distribution) of application packages to the defined environments of selected customers.
General deployment steps include:
- configuring which builds of which application should be deployed
- [optional] downtime of services (for production environment)
- launching the ServerDeployer application
- starting the deployment
- when it finishes, checking for possible deployment errors
- fixing any problems (in case of severe problems, we rollback the deployment)
- [optional] end downtime of service (for production environment)
- fill the Release protocol
