- 24 Jun 2021
- 4 Minutes to read
Upgrading to BuildMaster 6.2
- Updated on 24 Jun 2021
- 4 Minutes to read
BuildMaster 6.2 is a major, transformative version that removes all legacy features from the product. We no longer recommend upgrading to it from BuildMaster 6.1, and this article is for informational purposes only.
Planning for Your Upgrade
Because this upgrade is more involved than previous upgrades, special support for it has been included with paid licenses. Simply use the Submit Ticket Form, put
6.2 UPGRADE in the "How can we help" section, and include the Legacy Features Dashboard Report Logs in the body of the ticket.
Regardless of when you started using BuildMaster, you wont be able to upgrade to BuildMaster 6.2 until the Legacy Feature Detector has been run and reported no legacy features. This means you will need to first upgrade to the latest version of Buildmaster 6.1.
We recommend to to BuildMaster 4.9.10, and then BuildMaster 6.1. See Upgrading from BuildMaster v3 and v4 to learn more.
If moving away from legacy features is infeasible, we recommend to install a new instance of BuildMaster 6.2 side-by-side, and migrating application-by-application to the new system. Your license will allow you use both instances, and you can migrate historical data using the application backup/restore functionality.
Changes in BuildMaster 6.2
BuildMaster 6.2 is a major upgrade, with a number of breaking changes and significant new features. Review this article carefully before deciding when and how to upgrade.
Breaking Change: Legacy Features Removed
All of the legacy components in BuildMaster have been removed. See BuildMaster Legacy Features for a complete list of legacy features. Most of these features have been hidden by default on new installations since v5 (2016). If you're still using any of them, pay special attention to the migration strategies in this document.
All legacy executions logs (from legacy deployment plans) will be removed upon upgrade. To retain legacy execution data, you can export applications; those will be re-imported as non-legacy executions.
New Feature: Releases are now Optional
Builds have always been tightly coupled to releases in BuildMaster, but there are many situations where builds and deployments ought to be performed without being part of a formal "release", such as:
- Early/testing builds created via Continuous Integration processes that will never be released
- Simple applications (such as documentation or other static content) that don't require a change management process outside of source control or merge requests
- Deployment of imported artifacts imported from drop paths or continuous integration servers
To better support this workflow and make it easier to get started adopting BuildMaster, we've added the ability to create builds that aren't associated with any release at all.
New Feature: Enhanced Pipeline Deployments & UX
When promoting a build to a pipeline stage, this promotion itself is now run using the OtterScript runtime. This enables more advanced deployment scenarios and allows you to control more aspects of deployment using custom OtterScript. The Pipeline Editor and UX was also rewritten and improved.
- Run pre-deployment scripts to configure variables used later in the deployment, shut down-services, or otherwise prepare for deployment
- Use variable expressions for target servers or roles
- Run post-deployment scripts that can clean-up after deployment, send notifications, etc.
- Have a single, unified logging experience for the entire deployment to help diagnose problems
Instead of using Pipeline Stage event listeners, post-deployment-step tasks are recommended.
Existing Pipeline Stage Event Listeners are executed very differently now, and custom ones may not execute. Make sure to test them first.
New Feature: Support for Externalized Assets (Rafts)
Deployment plans, OtterScript modules, scripts (PowerShell/sh), and pipelines can now be stored in external repositories called Rafts. This allows these resources to be stored in places other than BuildMaster's database, such as in a Git repository or a file system directory.
Prior to 6.2, all of these assets were stored in BuildMaster's internal database, and were generally referenced by a surrogate key (i.e. a pipeline id) instead of by name; while we never supported referencing these identifiers, if you did, they will no longer work.
All of the underlying storage tables (Pipelines, Deployment Plans, Templates, etc.) will be migrated to the
RaftItems table and existing tables dropped.
Updated Feature: Resource Credentials
Resource credentials have been updated to split the concept of "secure resources" (third-party connection information) and "secure credentials" (secrets). This way,
connections to external systems can be configured in a consistent manner, but use different types of credentials depending on the API.
Existing credentials are not touched and should function as the did in previous versions, and may be converted to the "split" style in the UI.
You can only upgrade from BuildMaster v6.1. To upgrade:
- Run the Legacy Feature Detector and ensure there are no features
- Download and run the Inedo Hub from my.inedo.com/downloads or use the latest traditional installer
- Remove old (Legacy SDK) extensions as appropriate
- If you are using the
SqlServer 1.0.0extension, it will not load; delete it and download
- Upgrade/install the 6.2 extensions as needed
- Make sure that your BuildMaster database is backed up prior to upgrade
- Make sure that your Encryption Key is backed up prior to upgrade
- Make sure that the installation's \Extensions directory is backed up prior to upgrade
Because there are database changes, a rollback will require uninstalling BuildMaster, and then restoring your BuildMaster instance.