Add the Deployment Framework to source control
You may want to distribute a managed version of the Caplin Platform Deployment Framework to developers. This makes it easier to distribute upgrades to the Deployment Framework, and to share changes to commonly used blade files in the global_config directory. Here’s how to do this…
Your source control system must be able to handle the links in the Deployment Framework’s directory structure. In Cygwin, the Deployment Framework links are Windows shortcuts. |
Follow the steps below:
-
Unpack the new version of the Deployment Framework to a location suitable for adding the files to source control.
-
When the Deployment Framework is unpacked, the name of its topmost directory has the build number appended to it. Rename the directory to remove the build number.
-
If the Deployment Framework has been unpacked on a Windows machine, run the command script
<Framework-root>/kits/bootstrap.sh
. -
Update the files in <Framework-root>/global_config/ to add any generic global configuration items as required.
For example, it’s a good idea to configure some or all Platform components in development environments to generate DEBUG level log messages (see Logging in DataSource applications). To set this up, for say MyAdapterBlade, create a configuration file myadapter.conf in <Framework-root>/global_config/overrides/MyAdapterBlade/DataSource/etc/, and add to it the configuration item
log-level DEBUG
. -
Update port numbers in <Framework-root>/global_config/environment.conf
The Deployment Framework comes with a set of default port numbers for the core components, defined in <Framework-root>/global_config/environment-defaults.conf These port numbers can often be used unchanged on the machines onto which the Frameworks will be copied. However, if they’re not suitable, update them as described in How can I… Change Liberator and Transformer port numbers.
-
Set up hostnames for pre-configured Adapter blades.
For convenience, you can set up the hostnames for any Adapter blades that are already in Framework’s kits directory. To do this, use the command ./dfw hosts - see Change server hostnames in How can I… Change server-specific configuration.
If your Deployment Framework is only to be used in a development environment where a deployed Adapter blade only has a single server (no failover), the Adapter’s hostname can be set to localhost
, otherwise set it to the actual hostname of the server on which the Integration Adapter is to run.You may want to add to source control any kits in the <Framework-root>/kits/ directory. For example, Liberator, Transformer, any Caplin-supplied Blades, and locally developed blades.
-
Deploy the kits by running
./dfw deploy
This unpacks the kits and moves the original kit files (.zip or .tar.gz) into the kits/archive/ directory.
-
Move the kit files out of the kits/archive/ directory, so that they don’t end up taking space in the source control repository.
After following the steps above, don’t run any more Deployment Framework (dfw) commands on this new version of the Deployment Framework. Use the structure as the master copy under source control, and for putting subsequent Deployment Framework upgrades into source control.
Other developers can subsequently run Deployment Framework commands on copies of the Framework that they’ve obtained from source control and installed on development and production machines.
-
Add all the Deployment Framework files to source control:
-
Make sure that you preseve the Framework’s directory structure.
-
Make sure that that all empty directories are included. Depending on your source control system, it may be necessary to add a dummy file to each such directory to force the creation of the directory.
-
If the source control system supports file attributes:
-
Add all the files under global_config as writeable.
-
Add all the other files as read-only.
-
Add all the scripts in the <Framework-root> directory and in the kits directory as executable.
-
-
See also: