Git integration
Based on the PM, another important tool from software development can be used for development in Automic Automation with Git integration. A version control system such as Git is often used so that developers can save and restore the status of their implementations at any time. In order to be able to use such functionalities during development for Automic Automation, there are the Git Integration modules. These provide an interface to a GIT repository. This allows implementation statuses of packages in repositories to be saved and restored.
Rules for synchronization
The following rules are applied when synchronizing objects with the Git repository:
- All objects of the package that are in the Git repository are overwritten with the version.
- All objects of the package that are located in the Automic Automation Engine and are not in the Git repository are deleted.
- All objects of the package that are in the Git repository and not in the Automic Automation Engine are added.
- Folders of the package that do not exist in the Automic Automation Engine are created.
- Folders of the package that are not in the Git repository but are in the Automic Automation Engine are deleted.
The rules for folders also apply to empty folders.
Branches
To allow developers to support multiple versions of a package, the b4A modules provide the option of opening branches in the Git repository. It is possible to switch between the branches at will and each status in a branch can be provided with a marker (tag) that can be restored at any time. This allows a high degree of flexibility during implementation. The following section presents a concept for dealing with branches and markers. It is only an example and the use may differ from this procedure.
*1st example
It is assumed that there is exactly one branch that contains all versions that have ever been installed in the production system. Developers can open any number of branches for development versions. As soon as a development version from another branch is considered stable, it can be imported into the branch for productive systems and tagged.
*2nd example
As in the first example, developers can open any number of branches for development statuses. However, the productive versions are not kept in a single branch, but a separate branch is used for each minor release, which is named according to the pattern <Major>.<Minor>. If corrections are required for a specific minor release, these are saved in the respective branch of the associated minor release and marked with a tag.
Repository
All modules for the connection to a Git repository must know the address and necessary access data for the repository. All modules have some configuration settings for this.
Repository URL The URL to the Git repository. Examples
Working directory The path to a directory in which the working copy is saved.
- VCS user
- The user name for accessing the repository if authentication is required
- VCS Password
- The password for access to the repository, if authentication is required
- VCS password file (command line)
- On the command line, this option is also available as an alternative to the VCS password option, with which the password
Index
In some scenarios, especially when using PromptSets, it can be helpful to have the list of Git repositories and their branches cached in the Automic Automation Engine, as accessing them works faster. For this purpose, an index can optionally be created that enables access to the package Git repositories.
To use the Git repository index, it must initially be created once with the module b4A Modul vcs.Index. The b4A Module vcs.BranchCreate and vcs.Push then update the index automatically. These modules require exclusive access to the index variable. If the variable is currently open for writing, these modules wait until the variable can be opened for writing.
Unlike the package index, there is only the global variant here. In the configuration file vcs.conf, a client is selected in an environment (naming a b4A connection) in which the index is written for all Git repositories. It is recommended to use the development client here. The key used is defined in the configuration file vcs.conf.
Configuration
The settings for the Git integration modules can be found in the vcs.conf file.
If the Git repository is located behind an HTTP proxy, this can be defined in the configuration file conf/vcs.conf.
vcs-http-proxy-host Name of the proxy server
- vcs-http-proxy-port
- Port on which the proxy is accessible
- vcs-repository-pattern
- If this value is set, a repository can be specified for all version control system modules. This value is a b4A expression that can contain the package parameter.
- vcs-type
- Backend for accessing a version control system. Currently only GIT is supported
- vcs-index-folder
- Folder in which the object of the Git repository index is stored
- vcs-index-variable
- Name of the XML variable of the Git repository index
- vcs-index-repositories-key
- Key in the XML variable in which the Git repository index can be found
- vcs-index-connection
- This setting defines the connection in which the XML variable can be found.
- vcs-index-exclusive-open-interval
- An interval in milliseconds that is used to define how long to wait between attempts when exclusively opening the index.