Git provides a decentral configuration management. Based on this approach other more sophisticated configuration management setups are possible. This page attemps to describes the configuration management setup used in inspectIT.
Repositories
Within inspectIT we differentiate between four areas where Git repositories reside:
- Developer Local
- Git Publish
- Git Release
- Hudson Local
Developer Local
Each developer has a local Git repository. This repository is only accessible by the developer and is located on the computer of the developer. For development most interactions with Git will be performed against the local repository. Remember you have access to all configuration management features without the need to access a remote server! A detailed view of how the repository is used can be found in the process description (LINK!)
Git Publish
The Git repository called Git Publish is a central repository on which developers can push their features/bug fixes once they are finished (or before that if more than one developer works on one feature, or another developer is dependent on your code). Note that interactions between developer Git repositories is discouraged although possible. The sole reason is, that you can never be sure when your fellow developer is in fact in house and thus when you may access the repository. The Git Publish repository is always accessible.
Git Release
This repository contains the current stable branch of the inspectIT development ("stable") as well as all previous releases. In addition to that integration managers may push to the "unstable" branch to integrate new functionality or bug fixes. The Git Release repository is readonly for all developers. Only integration managers may write to this repository!
Developers still have to access this repository to update their local stable branches with the remote one. Otherwise, they will never retrieve the changes done from other developers.
| Info |
|---|
The stable branch is updated by the Hudson integration if the unstable branch passes all tests. |
Hudson Local
The continuous integration platform Hudson watches the unstable branch and performs a full test of the branch as soon as new information is pushed to unstable. To perform these duties, Hudson has its own repository that is updated by means of a cron job.
Branches
inspectIT differentiates between the following branches:
- stable
- unstable
- release
- feature/bug
Stable branch
The stable branch contains the current state of inspectIT development. It is ensured that this branch fulfills all test cases (by means of Hudson)
Unstable branch
This branch is used by integration managers to integrate new functionality or bug fixes with inspectIT. Hudson monitors this branch and copies the new information to the stable branch if the commited information pass all tests
Release branches
For each release a release branch / tag is created. This branch may be used if hotfixes must be performed on a older version
Feature/Bug branches
For each functionality or bug that is developed/fixed, the developer creates a local branch. So each branch exactly contains one feature or one fix for a bug.
Process description
This section defines the development processes with respect to configuration management.
Bugfixing / Feature development
- The developer creates a local branch for the functionality/bug fix
- Depending on the target version the bug should be fixed in, it may be necessary to branch from an older release and not from the current stable (master)
- By default all features will be created using the current stable (master branch of Git Publish)
- The developer can commit as he likes to his local repository
- If the functionality is finished and tested, he pushes the branch to the Git Publish repository
- He notifies an integration manager to integrate the functionality
- The integration manager pulls the feature branch and inspects the code. If the integration manager thinks that the code is good enough he will push it to the Git Release repository (unstable) and thus initialize the hudson build to check the branch. If the integration manager has problems with the branch, he will notify the developer and request fixes