HCL Launch is an enterprise-grade continuous delivery solution built to deploy anything, anywhere. It uses a server-agent model to map and deploy applications, which can be made up of one or many components. These components are drawn from build servers and pulled from artifact repositories. There are many ways you can configure these components so you can pull those artifacts and files in to then be deployed.
At the highest level of the HCL Launch product, we have the application. The application is generally made up of multiple components, which are then mapped to environments that we want to deploy these components to. For each of these applications, we define a process for how this application gets deployed. For example, in a deployment process you can install the web server, database component, and database schema, and java file. Within each of these steps is the component process, which includes the scripts and the steps that the agent is going to run on that target machine depending on which environment we deploy the application to.
Each environment is made up of components. Component processes are very easy to customize with the drag and drop visual designer. In the HCL Launch environment dashboard, you can see the component version, the date it was last deployed, if it was deployed successfully, and access the deployment logs. This makes it easy to keep track of auditing, governance, and approvals, and is great for enterprise environments.
For each of your components, applications, resources, and environments, you’re able to templatize your processes so you can easily onboard many similar applications. For example, if you have many java components that follow similar processes and you want to share that deployment process, you can easily create a template to make that process simple and repeatable.
Another way HCL Launch makes your life easier is with snapshots. Snapshots let you create “golden” configuration bundles of versions that you know can be deployed together. Snapshots also allow you to lock specific versions of objects like properties, processes, and templates, so if those objects change since you’ve locked configuration on the Snapshot, you can still deploy the snapshot and be able to get the exact same configuration as if you were deploying at the same time you first created the snapshot. In other words, when you put a status on a snapshot, you know that the versions of each of these components were tested and can move forward together so you don’t run into things like dependency issues or mismatched versions.
You can schedule deployments to run now or any time in the future. The HCL Launch backend API is very open and documented, so it’s very easy to start deployments from a script or from a continuous integration server.
In the settings and configuration of the HCL Launch server, you can define roles for users and groups to control who can do approvals, who can view history, and who can run deployments. Roles can have separate permissions for each sub-type of your HCL Launch objects. You can easily split up role permissions depending on if a user is interacting with a Dev, QA, or Production environment. The settings section is also where you set up your plugins, which are a key capability of how HCL Launch works. HCL Launch integrates with hundreds of plugins for automation and source configurations.