Deltanji Overview
Deltanji is an automated Configuration Management system. It can be configured to manage a wide range of situations, from the development work of a small in-house team to the development and distribution for a large software house.
Deltanji manages your codebase by storing it in a database known as the library. As your applications develop, the library stores each version of every component, which allows you to easily track progress, audit and rollback changes.
Managing Your Workflow
Deltanji keeps your codebase under control by managing your developmental workflow. None of your codebase can be modified while it is in the library, so to make changes to parts of your software they must be checked out. When something is checked out a new version is made, and when the changes are complete it can be checked back in to the library without displacing older versions.
The main unit utilized in Deltanji is the object version. This is a logical grouping of one or more of the components of your codebase at its specific stage of development.
Note: Sometimes the term 'object' is used as short-hand for 'object version', or to refer to a component or group of components in the scope of its full version history.
A Deltanji workflow is structured around a set of locations that are linked together by transfer routes. Objects progress through the workflow and build up a version history when they are transferred between locations. Some locations are simply views of the library, representing that the object versions they contain are at a particular stage in the workflow. These locations are called library-view locations. A workflow may have, for example, a location of this type called 'InTest'. Other locations, however, map to a physical storage space where they can be executed and/or modified. These locations are called working locations, and usually map to a Caché/Ensemble namespace.
For eaxmple, in a very simple workflow cycle, a developer checks an object version out of the library by transferring it from a library-view location called 'Current' to a working location called 'DEV'. This creates a new version of the object that they can edit. Once they've made their changes, they check the new object version back in to the library by transferring it to a library-view location called 'InTest'. This transfer also automatically transfers the object version to a working location called 'TEST' where it can be executed by a QA engineer. If they are happy with it, they transfer it back to the 'Current' location.
Controlling Development
Deltanji helps you managing and track changes to your codebase by grouping changes into change requests. A change request represents a task, grouping together the object versions that are to be changed in connection to that task.
Deltanji can be set up to require user authentication, and all areas of both the interface and your workflow can be customized with multiple access levels. This helps users to easily find the areas of the environment that are relevant to them and prevents mistakes being made.
Deltanji automatically controls concurrent development, ensuring that no changes are lost or inadvertently overwritten. Instances of concurrent development can easily be identified and branches can be merged if necessary.
An editor can be interfaced with your Deltanji environment, meaning that changes are automatically recorded in the Deltanji database and objects can be checked in and out directly from the editor*.
Understanding Your Environment
Deltanji maintains a detailed audit trail of all changes and transfers. A complete record is available for each version of each object and for each date.
Various management reports are available from Deltanji, helping you to understand how work is progressing and where to focus attention. For example, the Checked-out objects report shows all objects which have been checked out and can be customized to display only those objects that have not been checked back in by the expected date. This provides control over work that had been started, but has been suspended or abandoned without being returned to the library.
Demonstration Videos
Introduction to Deltanji
This video introduces some of the key concepts in Deltanji.
Simple bug-patching workflow
This video demonstrates how a very simple bug-patching workflow might work.
Development workflow
This video demonstrates how a more complex development workflow might work, with examples of concurrent development.
See Also: Understanding Deltanji
* InterSystems Caché/Ensemble only