Upgrading to BuildMaster 6.2 (2020)
  • 24 Jun 2021
  • 4 Minutes to read
  • Dark
    Light
  • PDF

Upgrading to BuildMaster 6.2 (2020)

  • Dark
    Light
  • PDF

Do Not Upgrade to BuildMaster v6.2 from v6.1

If you are using BuildMaster v6.1, we recommend directly Upgrading to BuildMaster 7.0. Otherwise, you will need to Upgrade to BuildMaster 6.1 first.

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.

Using BuildMaster v3 or v4?

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.

Legacy Execution Logs Removed

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.

Custom Event Listeners May Stop Working

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.

Scripts, Pipelines, etc. migrated to Rafts

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.

Upgrade Process

You can only upgrade from BuildMaster v6.1. To upgrade:

  1. Run the Legacy Feature Detector and ensure there are no features
  2. Download and run the Inedo Hub from my.inedo.com/downloads or use the latest traditional installer
  3. Remove old (Legacy SDK) extensions as appropriate
  4. If you are using the SqlServer 1.0.0 extension, it will not load; delete it and download SqlServer 1.7.0
  5. Upgrade/install the 6.2 extensions as needed

Risk Mitigation

  • 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

Rollback

Because there are database changes, a rollback will require uninstalling BuildMaster, and then restoring your BuildMaster instance.


Was this article helpful?