Source & Binary Control Management
AlexandriaCM
AlexandriaCM Binary Control Management. A Binary Control Management system is a client/server application that allows the storage and retrieval of artifacts from a central repository. The term Binary is to differentiate this type of system from a Source Control System.
Find out more about how AlexandriaCM can help your build management challenges.
Binary Control Management (BCM)
Our Binary Control Management or BCM server is an elegant solution for that hard to solve problem of sharing libraries between teams without having to resort to a network fileshare, cluttering your source control or having your teams build each piece that is required to be part of the application.
It will also make creating an update solution around your application extremely easy. Since all of the artifacts are already versioned, creating a client that will check the server and pull the correct updates is a breeze.
SCM Tools
(TFS) Workitem Template Customization/Extension to Specific Process
- Custom Controls
- Time Entry
- Bridge Systems (custom development)
- Team Project Management
- Workflow customizations (including field layout and transitions)
(TFS) TeamBuild Integration
- Custom Tasks
- See Build Automation
- Monitoring Systems
- Build Status, Success/Failure Notifications
- Management Systems
- Central Dashboard Control for Invoking and Managing Builds
Build Automation
Custom tasks integrated into all build steps (developer and build management)
Custom tasks integrated into all build steps (developer and build management) No two company build systems are exactly alike, and we dare say no two application build systems are exactly alike. With that in mind we create our build scripts to be as property driven as possible, allowing the build manager to set up the call to build an application in the way that fits the application. This often requires custom tasks to be built for the build engine. Our specialties are MSBuild, NAnt, and Ant build scripts, but if the build system can be extended we can and most likely will extend it to fit the needs of the company.
Package Automation for Deployment (MSI, zip, etc)
A build is not ready until it has been packaged and made ready for installation. This includes creating the installable package whether that package be an MSI, zip, or other format. Most of the builds that we have created have an automated packaging system built into them. This means that the developers not only control what is being compiled, but they also control what is supposed to be packaged. We also handle those cases in which an application's configuration is prepared for installation (neutralization, tokenization), where we strip all the information that configurable and replace that information with a Token to be replaced at install time. This allows us to install to any environment and configure it before running the application.