Migrating complex bash scripts to UrbanCode Deploy

Is there any documents or guidance/best practices to help customers determine how best to migrate large numbers of custom bash scripts (with hard coded properties per environment) into UrbanCode Deploy. The challenge I see is that the bash scripts run a number of steps (many) under a single process and access environment variables through out the script. The scripts are also written such that each environment has a copy of the script (ugh) with the specific property values hard coded. Clearly a poor design that we want corrected. However, moving from such a bad practice to doing it correctly in UCD is not trivial. I'm looking for guidance such as a staged approach for handling the migration of the bash scripts into UCD.

1 reply

I just had some similar experience, on another workload scheduler product. That has similar architecture and methodology with uCD. All tasks was designed and managed in server side, and dispatched to distributed environment, and executed by agents installed on target machines. Before using that product, customer is also use shell script for all their jobs.

This is not direct ucd experience, Just FYI.

To migrate their shell scripts to product, normally, we follow such process:

1) Design and Split the whole jobs into component level modules.

Most customer's scripts don't have good design, and created and modified by many people.
Some scripts are very long, and lots of duplicate codes. So, in this period, I would like to work out the component level module, isolate the business logic scripts and infrastructure common scripts. In this period, we will not think about how much code we can reuse from existing ones.

2) Build up the application/component interface script code.

We will consider how to combine the component process(almost done in 1) to build application deploy logic, in this period, I would like to focus on the logic between components, and we cannot easily combine them, in this period, normally, we will find we have to go back to refactor the component script.

3) Stuff the components/app modules code

After the framework is Ok, we will go thru the all existing code, and pick the useful codes and put them into the 1 and 2.

Considering the script and code perhaps will be used by other product, or migrate again in future. I would like to classify all codes by ucd features related and non-ucd related.