Under the Hood - How the plugin works
It's great that the rollout building and deployment is all automated, but you might want to know what happens in the background with your valuable code and WMS system.
Steps in the Build Process
- When running a build plan using the option 'Run Build for Jira Release', the plugin goes through the following steps:
- Collect a list of Jira issues that are linked to the Jira Release. It makes a call to the Jira system and gets all the Jira issues that have the Jira Release number in the Fix Version field
- Scan the Version Control repository for all commits that include the Jira Issue numbers from the list of Jira Issues.
- Collect all files that are linked to these commits
- Sort and filter these files, and only get the latest version of each file
- Create a Rollout package from the sorted and filtered files. The end result is a standard Rollout package that could potentially be installed using the regular Blue Yonder WMS (manual) installation process.
- The Rollout is stored as an artifact (opens new window) in Bamboo for furter processing in later steps
- The Install Rollout task executes the following steps:
- Get the rollout (i.e. artifact) from the bamboo server. If the installation step is executed on a remote bamboo agent, it will download the rollout from the main bamboo server
- Read the env.bat file, mainly to get the path to the LES/temp directory and other system variables
- Copy the Rollout to the LES/temp directory
- install the Rollout by executing the regular perl command: perl rollout.pl [options] <rollout-name>
What Files and Versions are selected
The diagram below illustrates which file versions end up in which release. Basically, it's the latest version of a given file within the release.
Added, Modified, Deleted and Renamed files
The Build Rollout task deals with files that were added, modified or renamed in the version control system.
It looks at the latest version of each file within a Version/Rollout and determines if the commit 'action' was an Add, Delete, Modify, Rename or Copy.
In case of an Add, Modify or Copy, we just add the file to the rollout, so it will add or replace the file in the target environment during installation.
In case of Delete, it will add a 'REMOVE' statement in the rollout install script (as opposed to the regular 'REPLACE' statement)
In case of a Rename action, it will add the new file name to the rollout as new file. In addition, it will place a 'REMOVE' entry in the rollout install script for the old file name.
How are Files Sorted
Once we have all the latest versions of each file, it is important that files are installed in a certain sequence. This is mostly relevant for .csv files or other configuration files that update data in the databse.
Two factors are important here:
- certain data uploads are dependent on other data uploads to exist
- older configurations should not overwrite more recent configurations (within the same rollout)
Load data sorted by table name
In Blue Yonder WMS, there are no database constraints to prevent order lines from being loaded before the order headers are loaded for example. The standard way of loading data is to use straight database inserts. When using that method, it is not important which datafile is loaded first, as long as all data is loaded for a given rollout. For example, locations can be loaded before areas are loaded.
However, when projects customize the mload control files to use moca commands (e.g. 'create location') instead of database insert statements, then the load sequence does become important. This is because most moca commands do a reference check, for example to check if the 'area' exists before creating the location. The advantage of using moca commands instead of straight database inserts is that the mload control files can generate sequence numbers, can add descriptions and are more flexible with custom fields.
The Build Rollout task has a built-in list for sorting the Blue Yonder WMS tables in the right parent-child sequence. Future releases will provide a config file in Bamboo where this list can be edited.
Older data should not overwrite newer data
It is possible that there are multiple files updating the same data. For example, we could have two csv files updating the same 'policy' value in the Blue Yonder WMS. It wouldn't be a good practise to have that scenario, but it could happen nevertheless. If those two files ended up in the same rollout, they should be loaded with the oldest file first.
The Rollout Build task makes sure that files within a given directory are loaded oldest first and newest last.