The following enhancements are included in each release. In addition to various bug fixes.
Key Features/Enhancements in 2.0.6
- Report data updates
- Added load and contributor information to the metrics bar. You can view the average contributors and load for selected time period against a previous period.
- Added Throughput metric data to the metrics bar and value stream table.
- Update to deployment plan
- You can now pass application list as properties for UrbanCode Deploy and Jenkins tasks.
- New Security Audit report
- Report added to provide information about users and group associated with a team. The report included user permission and role information.
Problems with formatting of the Versions table and data have been corrected. The table now correctly displays the application and version.
In the About this Stage dialogue box contains a query to filter the stage fixed to display the correct data.
Issued fixed when running concurrent UrbanCode Deploy tasks and one of the tasks takes a long time to complete which caused other tasks not to complete.
Key Features/Enhancements in 2.0.5
- Jenkins processing updates
- Jenkins tasks are automatically failed if the integration with the Jenkins server is not available.
- Deployment plan update
- Release participants can now see list of assigned users and groups on deployment plan tasks.
- Bug fixes
- Dot Fixed problem when the dot history sometimes does not display.
- Fixed issue with applicable tasks not displaying unless the Applicable button is toggled.
Key Features/Enhancements in 2.0.4
This release includes an announcement about advanced capabilities using IBM UrbanCode Velocity and IBM UrbanCode Release. See IBM UrbanCode Velocity 2.0.4 includes IBM UrbanCode Release and delivers advanced capabilities for your organization’s DevOps processes document for details.
- Value stream updates
- A list of favorite value streams can be create by marking a value stream as a favorite. The list can be prioritize to quickly locate a value stream.
- License sharing
- Starting with UrbanCode Release version 184.108.40.206 and UrbanCode Velocity 2.0.4 a single pool of floating and authorized licenses can be shared by users of the two products. For example, an user assigned a authorized user license type can use the same license for accessing both UrbanCode Release and UrbanCode Velocity.
- UrbanCode Velocity users can now be assigned an authorize license key by selecting Reserve License on the Users page.
- Value stream updates
- A value streams Favorite list can be create by marking a value stream as a favorite. The list can be prioritize to quickly locate a value stream.
- Support added for
issue.sprints.activeas a stage query to the DevOps query language.
- New Pipeline Designer role
- The new Pipeline Designer role allows a user to edit a pipeline but not able to run it.
- Gate enhancement
- The rules and reason for failure is displayed when a gate fails.
- Performance updates
- The time it takes to load a list of Jenkins jobs when mapping a list to environment has been improved.
- Improved load time of previous environment versions in pipelines.
- Bug fixes
- Fixed overflow of application list when working with Jenkins jobs in pipelines.
- Integration containers are now automatically terminated if not needed. It used to be possible for integration containers to become orphaned and use system resources eventually causing MongoDB to crash.
- Fixed issue with VSM link rule integration names not updating if the integration name is changed separately.
Key Features/Enhancements in 2.0.3
- Performance updates
- Changes to code for paginating user tables has been changed to increase performance when loading user lists.
- Improvements made to processing of manual tasks to improve processing time and eliminate an error exception logged when an imported task did not have the groupsAndUsers property defined.
- Plug-in updates
- Parser type plug-in code has been updated to fix a problem with the NPM wrapper when there are no plug-in properties.
- Bug fixes
- Integration with UrbanCode Deploy 220.127.116.11 fails with HTTP status code 500. This has been resolved by UrbanCode Deploy 18.104.22.168iFix01.
- Bottleneck detection errors are not handled well for value streams with data creation errors. Algorithm updated and more verbose reporting when bottleneck detected.
- Edit icon does not display when hovering over chart.
Key Features/Enhancements in 2.0.2
- Deployment plans can add task dependencies from the UI.
- Plugin image versions are now displayed on plugin page.
- Improved reserved participants to include LDAP and SSO users and check reservation availability.
- Added LDAP and SSO users alongside local users in a single users list.
- Bottleneck detection is now based on Lead Time definition.
- Gating is now applied when trying to join a release.
- Fixed issue where, a brandnew snapshot not being synced, could prevent autopromotion in pipelines.
- Fixed issue where a previous input version could still appear as pipeline input.
- Fixes an issue where properties were not displayed if pipeline stages were skipped.
- Fixed an issue where dots needed to unlink properly to show in the correct stage.
- Fixed an issue where dots could show in wrong stage if team issues were linked to multiple integration IDs.
- Fixed an issue that only counted active users for the reserved participant count.
- Fixed issue that prevented parser plugin updates from taking effect.
- New upgrade script to remove overlinking from history so that long histories can show.
Key Features/Enhancements in 2.0.1
- Added deployment plan visibility into task pre-requisites and dependencies.
- Improved UI to display LDAP and SSO user list.
- The UCD Status Task was improved to only list UCD integration statuses participating in the deployment plan
- Fixed issue with reporting consumer service reconnecting to database.
- Fixed issue with defaultValue for plugin SDK custom properties not displaying in configuration UI.
- Fixed an issue where a Jenkins deployment would use the previous stage version rather than a selected version.
- Fixed an issue where Jenkins jobs might remain in progress if multiple jobs were being run in parallel.
- Fixed an issue with pipeline scheduled deployments where the select all applications would not deploy all applications.
- Fixed a problem with VSM issue filters causing an incorrect issue count displayed in the stage context menu.
- Removed duplicate events from VSM history.
Key Features/Enhancements in 2.0.0
Scalability of services
The main UrbanCode Velocity services can now scale to handle larger installations and greater amounts of data.
Locking of releases
The release manger can change a release status to lock. No changes can be made to the release after it is locked. Request for changes must be This gives the release manager control over last minute changes and ensures no changes are made after a final review. The lock is set on the Release Overflow page.
Users can now manually approve versions and gate environments based on approvals. The gate fails if approval requirements are not met. If a version does not pass all approvals the release manager can override the deployment. This feature provides for governance and compliance of open source tools and fragmented tools. This feature is located on the Environment Overflow page.
Built in reports
A new State of Sprint report allows for gathering statics of the value stream in relationship to a sprint. This report is helpful to a scrum master or manager in reducing risk of the current sprint and look at older sprints. You can access the report on the Reports page.
Using the plug-in SDK you can create your own plug-ins and upload them to UrbanCode Velocity. To access to the plug-in SDK, click Settings > Integrations > Download Plugin SDK.
Using machine learning, the model looks at current and previous state of a value stream to determine which stage the user should focus on first. This algorithm is always updating with new information to locate the next largest bottleneck. Types of bottlenecks include:
- Long Wait Time – the average time of stage is longer than any other by a substantial amount
- Batching – items pile up then are released at the same time
- In-Flow and out-flow mismatch
See the Value Stream page Metrics Bar or Metrics Table fields.
Contributor and Load Metrics
Two new metrics are now available: Contributor Count and Load Count
- Contributor count shows how many users are working on items in the Value Stream. The metric is based off the stages in Lead Time (work select -> customer) and counts how many unique individual owned items in those stages. Allows the tool to compare other metrics to rationalize about other metrics.
- Load is also based off Lead Time and is a count of all the items in the stages at any given time. This allows you to see if there is a correlation of how much work is truly in progress vs how much is getting done. Usually there is a sweet spot to not give too much work and get the right amount out. With both our metrics are in a state where we can start rationalizing about different strategies without customers and how to use them correctly. See the Value Stream page Metrics Bar or Metrics Table fields.
UrbanCode Velocity v2.0.0 supports MongoDB server versions: 3.6, 4.0, and 4.2.
Docker Compose installations automatically upgrade to 3.6. Helm installations require manual upgrade or installation of the MongoDB server to 3.6 or later. New Helm installations use MongoDB 4.2 according to the Helm chart.
No APARs are included in this release.
The following table is a cumulative list of fixes in the 2.0.x version stream.
|PI99806||Velocity 1.5.1 Upgrade could Prevent Access to Deployment Plans and Reports (Fixed with v1.5.2)|
|PI99805||Fixed Jenkins plugin that could break Jenkins Server|
|PI99803||Fixes a performance issue that could occur when integrating with an UrbanCode Deploy version older than v22.214.171.124|
Plan and prepare
For supported platforms and requirements you can dynamically
generate a system requirements report using the Software Product Compatibility Reports (SPCR) tool.
Install the server
There are two option to obtaining the installation package: online installer and offline installer. Both options require a master license key, which can be acquired from IBM Passport Advantage.
The online installer option for installing the product requires an internet connection for the entire process. It requires minimum storage for the downloaded package. The downloaded image contains only the Helm charts used to pull the product Docker images from a GitHub location. This is our recommended installation method.
Download the online installer package depending on the platform, the product is being installed.
After the download completes, start the executable file to begin the install process.
Use the offline installer to install Velocity without internet connection. You will still need internet connection at some point to download the installer itself. Once downloaded, the installer will include all containers needed to successfully install the product. For this reason, the offline installer is larger than the online installer and will require more time/bandwidth and disk space when downloading.
The installation package is available from IBM Fix Central. Search and select the installation package appropriate for the installation platform.
After downloading the installation package, decompress the contents into two directories: one for Kubernetes and the other for Docker Compose. See the documentation section on installation for instructions about how to install the server.
A product license key is required to install the product. To obtain a key, you must agree to the terms and conditions provided on Passport Advantage.
To learn more about UrbanCode Velocity, see documentation.
For help installing or using UrbanCode Velocity, post your questions in the UrbanCode forums. Tag your question with velocity.
To suggest an enhancement to the product, visit the RFE Community
For information from support, including FAQs, visit the IBM Support portal. You can configure the support portal to view information about specific products.
Starting in 2.0.0
Starting in UrbanCode Velocity v2.0.0, the MongoDB server 3.4 is no longer supported. UrbanCode Velocity v2.0.0 supports MongoDB server versions: 3.6, 4.0, and 4.2. For more information about out of service MongoDB server versions, see Mongo website.
- Docker Compose installations automatically upgrade to 3.6.
- Helm installations require manual upgrade or installation of the MongoDB server to 3.6 or later.
- New Helm installations use MongoDB 4.2 according to the Helm chart.
1.5.1 Improves Upgrade Support for all Prior Versions
All versions can be directly upgraded to 1.5.1 or later. Helm upgrades from 1.4.5 and 1.5.0 avoid previous complications. Velocity 1.5.1 also fixes an old issue that required versions older than 1.2.6 to upgrade to 1.2.6 before upgrading further.
NOTE: Helm upgrades from versions prior to 1.5.0 still require
helm delete --purge <release_name>
Starting in 1.5.0
Starting with v1.5.0, we have added and modified some Helm Selectors to adhere with best practices. Therefore, running the
helm upgrade command from a previous version of UrbanCode Velocity will fail. All upgrades from a version prior to v.1.5.0 to v1.5.0 or later will require a Helm purge as described below.
- Delete your currently installed release with
helm delete --purge <release_name>, where
<release_name>is the name of your current UrbanCode velocity release.
- Follow the normal install directions with all previous name and values from your previous release.
Note: Your Mongo database will be not be modified as it is maintained outside of the installation.
Starting in 1.4.5
In v1.4.5, the distributed version of MongoDB was upgraded from v3.4 to v3.6. Docker Compose installs will see the upgrade happen automatically. Other Docker platforms, such as: OpenShift and Kubernetes will need to manually upgrade their MongoDB instance. MongoDB v3.4 is still supported as of the release of v1.4.5. However, MongoDB v3.4 has been End of Life by Mongo, so we recommend customers upgrade at their earliest convenience.
Going forward, when our shipped version of MongoDB is upgrade, we continue to support the prior version of MongoDB, but deprecate the version before that. For example, when the shipped version of MongoDB is upgrade to v4.0, support is continued for v3.6 and and v3.4 is deprecated. We estimate that this will require two MongoDB upgrades per year, which should not force our Enterprise Docker Platform users to upgrade their MongoDB image more than once a year.