OstaraUpgrade
This is a command line tool which applies all the application upgrade operations. It works on a local directory structure and is designed to be plugged into the task execution workflow of the Ostara Service.
The tool recognizes the following command line arguments:
-a,--disableAddons <arg> Comma separated list of addons to be
disabled. Available addons: List(...)
-b,--disableBackup Do not take back up of the modified files
-d,--taskid <arg> [Web UI only] Upgrade task ID
-E,--deleteEbaProject Physically deletes the EBA project, not just
the reference from the top-level POM
-f,--forceLatestVersion Force updating versions of missing
dependencies to the latest in platform repository
-h,--help Displays this help.
-i,--input <arg> The project's root directory which contains
the top-level pom or full path to the pom
file. Defaults to pom.xml in current
directory.
-R,--platformversion <arg> The project's platform version. Defaults to
2.1.1-RELEASE
-s,--skipAddons Do not run any addon operations (e.g. SLF4J
Migrator).
-t,--appTypeOverride <arg> Override the platform app type (one of Web,
Service, Messaging or Batch). It will be
autodetected if not specified.
While its architecture is generic, Ostara Upgrade ships with built-in features for Java code bases using the Java EE APIs and projects managed by Maven. Its pluggable design allows extensions with support for additional languages, frameworks and tools. Due to its permissive Apache license the extensions can be both open-source and proprietary, depending on the needs of organizations. Our recommendation is for open-source extensions since they can leverage the mindshare of the open-source community and is the widest distribution channel to the largest possible number of users.
The key feature of Ostara Upgrade is the platform version range specific transformations and their chaining. This works with two abstractions:
- the upgrade step
- the upgrade path
Below is an example Ostara configuration.
Describes all the operations that are to be performed on a project to upgrade it from a version to the subsequent one. As platform versions are released, each new release will add changes to the collection of APIs that it ships with.
The Ostara Upgrade module was designed for a typical Major.Minor.Micro versioning scheme. By convention, micro releases contain only bug fixes that do not break backwards compatibility. Minor releases will add features but preserve backwards compatibility. Major version releases may break backwards compatibility.
Upgrade operations performed by Ostara are designed for minor and major platform upgrades.
An upgrade step designed for major version upgrades should attempt to automatically transform the project structure to the new APIs and conventions that the backwards incompatible changes introduce. This will minimize the amount of manual changes that the users of the platform will have to make in order to be able to start using the new features of the platform.
While upgrades to minor versions do not come with backwards incompatible changes, they very likely do come with formally or informally deprecated APIs. An upgrade step designed for a minor version upgrade can automatically transform the application code base to use the new recommended APIs.
An additional use case is for emergency upgrades. While releasing a new platform version to patch a high severity bug might not be feasible, overriding one or more artifacts could be the faster way to release the patch. A dedicated upgrade step can then be combined with a mass rollout features to that all users of the application will get the patched platform in a very short time frame.
Parent class: org.ebaysf.ostara.upgrade.paths.UpgradeStep API: Link to the JavaDoc and/or code
An upgrade path is a sequence of upgrade steps. It is constructed dynamically at runtime by Ostara Upgrade based on the source platform version that is detected within the application and the target version that is specified to or detected by Ostara.
Parent class: com.ebay.raptor.platform.upgrader.paths.UpgradeAddon Executes arbitrary logic on the project's files. All registered in UpgradeAddonRegistry.
Addons attach to upgrade steps and they are intended to encapsulate upgrade logic that is not supported by the upgrade step API.
UpgradeMain.main
- migrateAll
- analyze/migrateProject
- processProjectModules
- processModule
- migrateProject
- for every upgradePath: preprocessProject
- migratePom
- for every upgrade path: processWebOrServiceProject/processLibraryProject/processBatchProject/processRegularProject
- for every upgradePath: postprocessProject
- for every upgrade path: run addons
- migrateProject
- processModule