How good is uDeploy for Enterprise ?
A overview of uDeploy — a tool for automating application deployments through your environments
My gosh! Such a powerful tool that I came across. Originally called Urbancode Deploy, later acquired by IBM and renamed it to uDeploy. It’s a product that could be the end state of a CI / CD process, primarily focussed on deployment of application to servers, public cloud etc. It’s an agent based system, where a small agent (groovy based) runs on the every instance and when a deployment is made, the agent gets notified and the process as defined is executed.
It can be tailored to fit for various use cases, where the release management has to happen in a controller manner and every release has a potential to be audited on necessity of the release (business / tech mandatory / security aspect), who made the release, who approved it.
To begin with, there are multiple hierarchies — applications, application processes, component, component processes, environment, and other security controls. There are tonnes of role customizations can be incorporated within to follow the least privilege access methodology.
An Application represents the main entity — that’s tagged with the Application ID. Under an application, we can have different environments (like DEV, SIT, UAT, PRE-PROD, PROD, COB etc), and all the processes that you define can be executed on all of the environments (or can be customized not to execute on certain as well).
A Component Entity is an analogy to a module deployment — say a spring boot war deployment on tomcat / IBM WAS server, or Oracle Database deployment. This is the entity is being tied up with the binary (war / ear / sql files etc), which is built by the CI instances (Jenkins / TeamCity / Circle CI). A comp-process can be as small as stopping a tomcat instance Or can be as big as stop-instance -> deploy the new changes -> start-instance -> perform health check. So, it all depends on the use cases and how modular you would prefer to have the steps. Once the artefact is deployed and successfully tested in lower environment, the same version can be moved to higher environment. It readily follows the concept of build once and deploy multiple times.
An application can also have multiple Application Processes which in turn is a combination of various component processes — which are essentially combines the processes to simplify the deployment. Ex: if you want to have all the modules (database, frontend, backend, config changes) to be deployed at one shot — like One Single Click, you can design it accordingly.
Not to forget that we can have configuration variables at every level (component, component process, application & application process as well) — making it much more customizable and writing generic modules for deployment.
Lemme address on the security metrics as well. We can create various groups, and can map it as per environment — like DEV, SIT, UAT can have a set of approvers (like QA testing team, or SDE-III Developers) while PROD/ COB can be left to application managers Or Production Support Team to approve, as it will be much tightly controller. And for DevOps Engineers — a configuration group is allocated where they get to configure and create the above processes / steps as desired.
One Amazing feature is it integrates well with the ServiceNow suite, so during a Production Deployment only a valid ticket (in appropriate state) will be executed, making it perfect for auditing.
Few major setup I have been involved:
- Created a DB Pipeline that could deploy different code (As well same) to 16 different Database instances — all simultaneously, with proper log management and failure tracking for every instance.
- An End-to-End setup for deployment of 300+ java based binaries, 200+ configuration files, 300+ shell scripts.
And Of Course, It’s truly a Single-Click-Deployment.
-cheers
