The scope manager is a service that allows to manage different scopes when auditing Agile teams. It is mainly used in Bluejay Infrastructure due to the necessity of managing agreements for different teams within a same class or organization.
When using the scopes manager, an agreement template is created for one class or organization. Then, different teams within that class or organization register towards the scopes manager to get their own agreement based on the template. This interaction is shown in the following diagram:
The join service is a component that helps registering the team and creating the agreement. All requests could be made manually using a REST client. Agreements are not automatically created upon registration since some team may want to be registered but do not be audited until a certain moment, thus, the agreement is created when the team is ready to be audited.
Scopes are typically generated based on a GitHub project. To do that, there must exist an
info.yml file in the root of the GitHub repository. This file contains the information needed to generate the scopes, so the scopes manager can validate it and generate the scopes through its API. The file is structured as follows:
The scopes file is stored in the private directory of the Assets Manager service. It is a JSON file that contains the different scopes that can be used in the agreements. The file is structured as follows:
A class is a group of teams that share the same agreement template. The class is identified by its
projects fields are used to define the scopes for the class.
The identities define the scope of each project or the class. Thus, Identities can be defined at class level or project level. The concrete definition of an identity depends on its
source, since it may require more fields. The following table shows the different sources and the fields required:
|github||repository, repoOwner||The repository of the project and the owner of the repository.|
|pivotal||projectId||The id of the project.|
|heroku||projectId||The name of the application.|
|travis||-||No fields required.|
|codeclimate||-||No fields required.|
The credentials are needed in case the identity requires authentication. The credentials are defined in the same way as the identities, the required fields to define credentials are
Projects are a lower level scope. They are identified through a
projectId and a
owner field is used to define the owner of the project. The
credentials fields are used to define the scope of the project. The
members field is used to define the members of the project. The members are defined in the same way as the projects, but they are identified by a
memberId instead of a
Members also contain identities which identify their username or account in the different sources. Credentials may be defined at member level, but since they all belong to the same team, they are usually defined at project level.
The Scopes Manager service exposes a REST API that allows to manage the scopes file. The following table shows the different endpoints:
|GET||Gets all the classes or organizations|
|GET||Gets the class or organization with the given id|
|GET||Gets all the projects of the class or organization with the given id|
|GET||Gets the project with the given id of the class or organization with the given id|
|GET||Gets all the members of the project with the given id of the class or organization with the given id|
|GET||Gets the member with the given id of the project with the given id of the class or organization with the given id|
|POST||Generate scopes from a given GitHub list of projects|
|POST||Check the info.yaml from a given GitHub list of projects|