Application Version Baseline Procedure

[SaschaWildgrube]

After a sprint, or whenever a new feature has been completed it may be a good point in time to release a new version of an application.

So, whenever the development team considers the state in the application’s “dev” branch ready for a deployment, the following activities should be conducted:

1. Run the Code Sanity check on the app (using Instance Scan). Ensure the app has no findings. Fix findings if necessary and start over.
2. Run all available ATF tests – and fix issues if any tests fail and start over.
3. Insert or update documentation on technical debts and adapt switches to turn features on or off to match the product owner’s expectations and decisions regarding
   1. Unfinished work
   2. Features not (yet) to be released to users
   3. Deprecated features
   4. All other forms of technical debts
4. Insert or update dependencies of the app (i.e., update the minimum version requirements).
5. Document all changes relative to the previous version in the application’s release notes.
6. Review and update feature descriptions in the application manual
7. Set the application version in the application settings (if not done already).
8. Commit all uncommitted changes to the “dev” branch.
9. Click on the “Baseline” UI action on the application form (if the DevTools open-source application is installed, otherwise the following tasks must be performed manually):
   1. Repair several application files which may be modified by the users or even by the platform by mistake.
   2. Commit all resulting changes to the “dev” branch.
   3. Create branch and name the branch exactly like the version of the application (e.g., “1.5.0”).
   4. Switch back to the “dev” branch.
   5. Add the postfix “WORK IN PROGRESS” to the application name
   6. Create a new section in the application’s release notes (if they exist in the application manual UI page)
   7. Increase minor version number (and optimistically assume that the next version will deliver a backwards compatible new feature)
   8. Commit all resulting changes to the “dev” branch.
10. Lock the new branch in the source control system

Performing all these steps manually is obviously laborious and prone to human error. It is recommended to automate as many of the steps as possible. To do so, the following technical capabilities need to build – as these are not provided OOTB:

• Provide a user interface to trigger the baseline procedure
• Ensure that the application is ready for baselining
• Clean up application files and remove any unintended files
• Commit pending changes, create the new version branch and switch back to the “dev” branch
• Increase the version number
• Add a section to the release notes
• Lock the new version branch to prevent further changes

The open-source applications “DevTools” and “Deployer” support all the required technical capabilities.

More information about DevTools can be found here:

https://www.wildgrube.com/servicenow-devtools

More information about the CodeSanity app can be found here:

https://www.wildgrube.com/servicenow-codesanity

More information about the Deployer app can be found here:

https://www.wildgrube.com/servicenow-deployer

The whitepaper about a mature development and deployment process can be downloaded here:

https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf