BODS Repositories

[Former Member]

Introduction

This document provides information on the types of BODS Repositories (Local, Central and Profiler) that should be set up and the number of repositories of each type that can be set up in various environments (Dev, Int, UAT and Prod).The actual number of repositories will depend on project specific requirements.

This document can be used as reference to work out the actual number of repositories required. This document does not explain how to create various repositories, how to use central repository, configure groups and users, assign access to users for repositories etc as these are already detailed in BODS Technical Manuals.

Considerations and Assumptions

• Consider there are 4 BODS environments

Development (Dev)

Integration/Pre-UAT (Int)

Quality Assurance/User Acceptance Testing (UAT)

Live/Production (Prod)

• Only Development team creates/modifies the code, this is to stress on the point that Production Support team is not allowed to modify code directly in Prod environment.

• It is assumed that all developers are working at the same time; if all developers are not working at the same time then Local Repositories can be shared between developers.

• All developers are part of one team/Project (example one DWH application), If there are multiple teams then the repository set up should be replicated per project/team.

• Code is developed/modified only in Dev environment and then progressed/migrated to Int-->UAT-->Prod. Developers do not have designer access to any env other than Dev env.

• It is assumed that developers do not have rights for code migration. Code migration is done by some other team (example Release Management or SAP Admin or Support Teams).

• Code migration can be carried out in one of the two ways; Lower env Local Repository to higher env Local Repository (Direct) or Lower env Local Repository to file and then file to higher env Local Repository (Indirect). Indirect method has less risk and is easier to troubleshoot in case of issues because of deployments.

• It is expected that a back up of current code in higher env is saved as a file before new code is imported to enable roll back when necessary.

BODS Repositories

Below table provides information on the number of repositories of each type required

	Dev	Int	UAT	Prod	Comments
LR	N+1	1	1	1	N LR’s in Dev env for N developers and 1 additional LR as MR. Minimum 1 LR in each environment is mandatory for Jobs to run.
CR	1				CR is optional however it is highly recommended that a CR is used even in single developer projects.
PR	1	1	1	1	PR is completely optional and only required when basic data profiling is not sufficient.

N: Number of Developers.

LR: Local Repository.

CR: Central Repository (Only Secure Central repository is considered).

PR: Profiler Repository.

MR: A Local Repository specifically for Code Migration (Code promotion) purpose in Dev environment however no code changes are carried out in this, Only Development Lead/Code Consolidator is allowed to access this repository.

Explanation

N Local Repositories in Dev environment and 1 Local Repository in each higher environment would meet the minimum number of repositories required for base level of functioning then what is the need for Central Repository and an additional local repository just for migration purpose in dev environment?

Need for Central Repository

Central Repository supports multi user development as it enables parallel development and hence reduces development timelines, for example developers can work on different DataFlows which can later be integrated into a Job. Even though Central Repository is generally used in multi developer scenarios it is found that using central Repository in single developer scenarios can also be very useful as it also provides version control and code comparison options (especially comparisons with dependents option) within BODS tool and these features can save lot of time and effort during development/enhancements.

Need for an additional Local Repository as Migration Repository in Dev environment

There are two key reasons for including a migration repository

1. Without a separate additional repository in Dev environment for migration purpose it is very difficult for development team to test consolidated BODS code.
2. Even though central repository can be used for consolidating code from various local repositories it cannot be used for code migration. For code migration (export/import) a local repository is mandatory.

The way to use migration repository is explained below

Ensure migration repository is in sync (same code as in Prod). Once all the developers check in their code into central repository a Development lead/Code consolidator can get the consolidated code from central repository into migration repository and run the Jobs and check if the integrated BODS code works fine as expected and then this repository can be used to export the code into a .atl file for code promotion.  Without this repository, the Developers would work on their local repositories and then one of the developer’s local repositories would have to be used for code consolidation and code migration to Int environment. This approach will have multiple risks and limitations. The developer whose repository is being used for consolidation will not be able to work on other changes.High chances of unintentional code changes progressing to Int environment. Also there is a risk of code corruption and hence corrupted code progressing to Int environment when developer’s local repository gets corrupted.

Hope this document helps those who are new to BODS and are setting up BODS repositories. Also, I am interested  to know from other BODS Professionals about repository set up in your respective projects. 

Thanks