What's New in HCL Launch 7.1.2.0 

Our continuous delivery platform, HCL Launch, has been updated with new features and functionalities so it’s easier than ever to deploy software quickly, securely, and smoothly. Keep reading to find out what’s new in HCL Launch 7.1.2.0.   

Artifact Retention Configuration View

HCL Launch simplifies deployments by being able to store build artifacts inside their very own file repository. Holding onto these artifacts allows HCL Launch to make simple, repeatable deployments with a specific version for as long as those version artifacts exist inside the HCL Launch server.

However, you are most likely not interested in holding onto all artifacts forever. Previous versions of HCL Launch introduced our Artifact Cleanup functionality in which the HCL Launch server will archive versions out of the artifact repository if they are older than a specified age, or if they are not part of the latest N artifacts imported for that component. These settings can be specified in three different places: 

1. globally in the System Settings page 
2. at the Component level 
3. per Environment 

This enables powerful combinations to best meet your organization’s retention policies, but managing cleanup policy in three disparate views can be challenging.

To simplify configuring your retention policies, we are excited to introduce the new Cleanup Configuration page. Users granted the new “Bulk Manage Cleanup” permission are able to access this new page via the Settings tab, and from there can manage the cleanup settings for a birds-eye view. 

The new page has two views: Components and Environments. The components section lists all components in the server, the total size of their versions, and the version-keep values being used. The basic table can be used to identify interesting items such as the largest contributors to disk usage or which components have the most/least aggressive retention settings. One or more of the visible components can then be selected and a dialog can be opened. This dialog allows the user to update the retention settings across all selected items either to new fixed values or to use the system cleanup values 

The environments section lists all environments in the server. Similarly, this allows one to see the snapshot, version, and deployment history retention settings, both the values and if it is specified by the system or environment template configuration. The environment entries are modified in an identical way to the component entries, but if you’re modifying an environment whose cleanup values are inherited from a template you will be affecting every environment that is associated with that template. 

All in all, this new view is a great asset in configuring the ideal retention policy! 

Snapshot Gating

Quality gates are a powerful and flexible tool to ensure that new versions of applications are absolutely ready to be deployed to a target environment. These gates work by checking a deployment manifest to make sure that all versions have the required status, or that no version in the deployment payload have a restricted status applied. When deploying a Snapshot, all versions included in the snapshot are checked against the quality gate. 

Snapshots make managing your “golden set” of deployment materials simple, so we wanted to make it even simpler to use snapshots in quality gates. Snapshot statuses can now be specified in the set of conditions on a quality gate – if a snapshot status is required or forbidden, then that condition must be met on the snapshot that is being deployed. These conditions can be mixed and matched with version conditions, which allows you to ensure that individual versions have been given statuses like “Build Succeeded” or “Tests Passed” but also that the snapshot, which represents the composite of your application component versions, has been checked. In other words, you can use quality gates to check that individual pieces of an application and/or specific versions of the application satisfy release criteria. With snapshot status gates, you can govern your snapshot–based deployments with a single check. 

OAuth 2.0

With 7.1.2.0, HCL Launch can now defer authentication to systems that implement the Open API Connect 2.0 specification. Now, user authentication management can be seamlessly shared between the other applications in your organization. Read a more detailed write-up of OAuth 2.0 in this blog post.

Secured Post Processing Scripts

Post Processing Scripts are JavaScript based scripts that can be configured to run after a step completes. This script is typically used to process the step’s output log to add new properties, or change the success status of that step.

Historically, Post Processing Scripts have been able to be viewed by any user that can access the settings tab or the process editor, and only users with the global “Manage Post Processing Scripts” permission could edit it. We wanted to integrate the flexibility of our security model to these scripts, so we have added a whole new set of permissions, and now allow assigning teams to them. 

The ability to assign teams to Post Processing scripts means that access to these scripts can now be gated behind role membership on teams. Instead of giving a user access to modify every one of these potentially critical deployment scripts, now only those in a role that gives Edit permission on that team can change scripts that are potentially critical for your team’s deployments. 

Only users who can view a script can assign that post processing script to a step, so these new permissions also open up avenues to restrict usage of scripts. Scripts that aren’t ready for use can have team-mappings withheld and then they will not be able to configured until teams are added. Once a post processing script is added to a step then it will be able to be executed as part of the process execution regardless of the executing users’ permissions. 

On upgrade, all existing roles will be given permission to view post processing scripts on that team. However, all post processing scripts that existed before upgrade will only be given a mapping to the system team. To preserve access to existing Post Processing Scripts, users on the system team could apply teams to the scripts, or all users could be placed on a “View Post Processing Script” role that gives read access in the event that your organization does not want to take advantage of the granular security access. 

See the updates in action 

Check out the on-demand webinar below to learn more about HCL Launch 7.1.2.0 and see a demo of the new features.