Global configuration

Set up access to package server

This setting is for all projects on the server. It has to be done once.

  • in ./bin directory copy to
  • edit and define software endpoint and set the phase:
name type description
IMLCI_PHASE string name of the phase; one of preview
IMLCI_PKG_SECRET string Secret to download software packages; recommendation: do NOT set a shared secret for all applications but an individual one
IMLCI_URL string Url to server with software packages

Set up software rollout

The deployment client can handle multipe profiles. One profile is for one application.

In the subdir ./profile is an example profile:

└── example
    ├── replace.txt


File Description Configuration file for the application rollout
replace*.txt Files containing replacement data. You can create multiple files eg. for different responsible groups like sysadmin, developers

Create a profile

  • Create a subdirectory in ./profiles/ for each product
  • The example subdir gives an orientation and can be copied, i.e. cp -r example myapp
  • create a config file named ./profiles/myapp/ (copy the from example profile)
# my install dir

# fileowner
# appowner="user:www-data"

# ----- settings for CI server software package 


# override global value 
# IMLCI_PHASE=preview

# cleanup after pre install tasks and bevore extracting data
# set both to 0 .. or only one of them to 1

Config variables:

name type description
installdir string target directory of your application
appowner string if not empty a chown -R will be applied in target directory by chwon -R ${appowner} ${installdir}; appowner is the parameter behind -R. It is something like “myuser.” or “myuser:mygroup”. For a web application it should be the user of your webservice (www-data/ apache/ nginx). The command chown requires to run the deploy script as root.
IMLCI_PROJECT string Project id in IML CI server
IMLCI_PHASE string optional: override the global IMLCI_PHASE in ./bin/; it is one of preview|stage|live
cleanup_preview 0 or 1 Cleanup preview - shows diff between downloaded TGZ and ${installdir}.
cleanup_force 0 or 1 Run cleanup: it deletes all files in target directory that aren’t in the last downloaded tgz. To keep runtime data like logs or uploads you can add a file .keep in the directory.

Make a testrun: ./ in application root. It should download the software package and extract it and install it into you ${installdir}.

Add hooks

If needed you can create hook scripts. The working directory is ${installdir} that you can use relative pathes to point to your files in the the extracted sources.

To access other ressources you can user these variables:

${selfdir}     application root of deployment scripts
${profiledir}  project config dir i.e. [path]/profiles/myapp

For hooks you can create files with pre defined names. A hook script must have executable rights. You get a hint message if it does not exist or has no x permission. A missing hook script does not result in an error.

  • profiles/myapp/ - do something before extracting the archive.
  • profiles/myapp/ - replace config files (see below)
  • profiles/myapp/ - do postinstall actions before finishing

Create configs for an application:

The script ./bin/ can read config templates and create an output file.

You need to reference the template, output file and a file for replacement data.

# ----------------------------------------------------------------------
# ----------------------------------------------------------------------

#         template_file                                 target_file                       replacements (can be multiple files)
#               |                   |                                             |                                 |
#               v                   v                                             v                                 v
"${selfdir}/bin/"   hooks/templates/mytemplate.erb                config/target.php                 ${profiledir}/replace.txt

During execution the working directory is the target directory of your application.

  • “${selfdir}/bin/” is the script that replaces config data in a template.
  • In your software repsoitory put a template into ./hooks/templates/. It will be found if the archive was extracted.
  • the target file is relative to your application root.
  • files with replacement data.

A sample replacement file is profiles/example/replace.txt:

# ----------------------------------------------------------------------
# ----------------------------------------------------------------------
# key=value
# - no spaces around first "="
# - value can contain any char, no quoting
# ----------------------------------------------------------------------



# ----------------------------------------------------------------------

The idea for several replacent files is that different groups can set their replacement data:

  • sysadmins add connections and credentials to needed services/ database connections
  • developers add api keys and other internal values

Pre and post install actions

Example: A simple can contain the start of a script that is delivered in the tgz archive.

# ----------------------------------------------------------------------
# ----------------------------------------------------------------------