AlexandriaCM Binary Control Management
What is 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.
The idea is that we can store reusable artifacts in a central location that can be shared between multiple groups, teams, or individuals. Clients will then communicate with the sever and retrieve the desired artifact from the repository. Because these artifacts are versioned the client can retrieve whatever version it is interested in without the worry of a previous version being overwritten.
We cover basic usages in several scenarios:
Company A Builds 15 Different Products
Public API Libraries
A company has a product that is easily extended and releases a public set of libraries to be used by its customers and independent developers to extend their product. Instead of creating an installer on a slow release cycle they publish their libraries to an AlexandriaCM BCM Repository. Or as a component team finds a bug they can easily and quickly publish the fix which can then be pulled immediately to all clients, if they so desire.
Common Architecture
A company has a Common Architecture team that spans the company's products. The Common Architecture team has 12 libraries that they maintain plus new ones coming online every few iterations. They have a responsibility to maintain older releases as well as come up with new features as the products they support require it. They can build and publish their builds to an internal AlexandriaCM BCM repository letting their customers pull at their own leisure when they are ready to upgrade.
Product Team
A product team has been split into multiple parts to handle the complexity of the application. The teams consist of Database, Core, Thin and Thick Client. The database team wants to stay ahead of the Core team, while the Core wants to stay ahead of the clients. Also no team wants to build the previous team's projects to get the libraries and although they can use a network share they opt to use an AlexandriaCM Repository to allow each the flexibility to use the necessary versions, get bug fixes (at their own pace), and use the integration into their IDE, without the overhead of the network file share restrictions.
TFS Security
Command line Reference:
msdn.microsoft.com/en-us/library/ms252587.aspx
Command-line permissions that are proceeded by a 'tf:' are used by 'tf.exe', others are used by the TFSSecurity.exe utility.
| Permission (Command-line name [, other names]) | Team Foundation | Team Foundation | Service Accounts | |||
|---|---|---|---|---|---|---|
| Allow | Deny | Allow | Deny | Allow | Deny | |
| Administer shelved changes (tf: AdminShelvsets) | x | x | x | |||
| Administer warehouse (ADMINISTER_WAREHOUSE) | x | x | ||||
| Administer workspaces (tf: AdminWorkspaces) | x | x | ||||
| Create a workspace (tf: CreateWorkspace) | x | x | x | |||
| Create new projects (CREATE_PROJECTS) | x | |||||
| Edit server-level information (GENERIC_WRITE, tf: AdminConfiguration, tf: AdminConnections) | x | |||||
| Alter trace settings (DIAGNOSTIC_TRACE) | x | x | ||||
| Trigger Events (TRIGGER_EVENT) | x | |||||
| Manage process template (MANAGE_TEMPLATE) | x | |||||
| View server-level information (GENERIC_READ) | x | x | x | |||
| View system synchronization information (SYNCHRONIZE_READ) | x | |||||
| Permission (Command-line name) | Readers | Protected | Contributors | Leads | Administrator | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Allow | Deny | Allow | Deny | Allow | Deny | Allow | Deny | Allow | Deny | |
| Administer a build (ADMINISTER_BUILD) | x | x | ||||||||
| Delete this project (DELETE) | x | |||||||||
| Edit build quality (EDIT_BUILD_STATUS) | x | x | x | |||||||
| Edit project-level information (GENERIC_WRITE) | x | x | ||||||||
| Publish test results (PUBLISH_TEST_RESULTS) | x | x | ||||||||
| Start a build (START_BUILD) | x | x | x | |||||||
| View project-level information (GENERIC_READ) | x | x | x | |||||||
| Write to build operational store (UPDATE_BUILD) | x | x | ||||||||
| Permission (Command-line name) | Readers | Protected | Contributors | Leads | Administrator | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Allow | Deny | Allow | Deny | Allow | Deny | Allow | Deny | Allow | Deny | |
| Read (tf:Read) | x | x | x | |||||||
| Check Out (tf:PendChange) | x | x | x | |||||||
| Check in (tf:Checkin) | x | x | x | |||||||
| Label (tf:Label) | x | x | x | |||||||
| Lock (tf:Lock) | x | x | x | |||||||
| Revise other users' changes (tf:ReviseOther) | x | x | ||||||||
| Unlock other users' changes (tf:Unlock) | x | x | ||||||||
| Undo other users' changes (tf:UndoOther) | x | x | ||||||||
| Administer labels (tf:LabelOther) | x | x | x | |||||||
| Manipulate security settings (tf:AdminProjRights) | x | |||||||||
| Check in other users' changes (tf:CheckinOther) | x | x | ||||||||
| Permission (Command-line name) | Readers | Protected | Contributors | Leads | Administrator | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Allow | Deny | Allow | Deny | Allow | Deny | Allow | Deny | Allow | Deny | |
| Create and order child nodes (CREATE_CHILDREN) | x | x | x | |||||||
| Delete this node (DELETE) | x | x | ||||||||
| Edit this node (GENERIC_WRITE) | x | x | ||||||||
| Edit work items in this node (WORK_ITEM_WRITE) | X | x | x | |||||||
| View this node (GENERIC_READ) | x | x | ||||||||
| View work items in this node (WORK_ITEM_READ) | x | x | x | |||||||
Directory Structure
The directory structure for a project should be set up in the suggested manner:
Definitions:
- Releaseable Project -A project that has its own release schedule. All folders underneath the project/trunk folder should be on the same release schedule. If an item is on a different release schedule it should be analyzed for a possible move to its own project folder.
This accomplishes several tasks:
- When the Trunk is branched not only is the source branched, but all items related to the creation of the application will be branched as well.
- Directory clutter that often results when there are several groups trying to use the same space will be reduced
- Build files will be placed in the build directory
- Custom or external tools will be placed in the tools directory
- Documentation can have its own space
- The extra directories (Database, Tools, Documentation, etc...) are optional and only needed if the project requires them. Build and Src should be required directories.
Build Directory
The build directory is used by the build manager to keep the source directory from being cluttered. This will allow build managers their own "space".
Src Directory
The Source directory (src) contains all items related to the applications source code. This is relatively loosely defined as it can contain custom tool code that may not be shipped with the application, documentation, etc... This decision is to be made by the development team.
| Version Sequence Name | Version Sequence Location | Definition |
|---|---|---|
| Major | Major.minor.Patch.Build | When the major sequence changes this signifies a large architectural change, in reality any change can happen at this level and there are not binding contracts. |
| Minor | Major.minor.Patch.Build | When the minor sequence changes this signifies that a smaller architectural change has happened. Obsolete'd code has been removed, and/or some significant API changes to public contracts. |
| Patch/Release | Major.minor.Patch.Build |
When the patch/revision sequence changes:
|
| Build | Major.minor.Patch.Build |
When the Build sequence changes:
|