# Example relyance.yaml Configuration File

The objective of the Relyance Source Code Inspector is to scan the source code, extract metadata, and display results in a meaningful way to assist our end users in taking action. The YAML file has 2 primary purposes:

1. It helps specify the directories that should be scanned vs. ignored.
2. It helps specify how the source code should be represented in Relyance to view the information appropriately. The Relyance YAML configuration file assigns product names, services, and tags to your scanned repositories. This helps logically section out source code and helps to filter products in the grid views/visualizations in Relyance.

This article below outlines best practices for designing the YAML and discusses an example YAML file.If the Relyance configuration file is absent in the source code repository, the Source Code Inspector will search for a '.git/config' file. In such a case, it will automatically create a YAML file, using the repository url as the repository name. If neither the relyance.yaml nor .git/config file is present, the source code inspector will produce an error message.

It is important to name your Relyance configuration file 'relyance. **yaml**'. Other variations will be ignored.

### Best Practices for configuring the YAML file

1. First, decide on the repo(s) that need to be scanned via Relyance. The YAML file is specific to a repo and needs to be placed at the root. For information on how to select repos, check this article.
2. Defining services: Break down the source code repo into services at an appropriate level of abstraction. For example, if the source code repo is logically organized in microservices, list the microservices as different services in the YAML file. If it’s a mono repo, it could either be abstracted as one single service or broken down into logical components that will make sense to view in the Relyance platform.
3. Defining Product(s): It’s critical to set an appropriate Product name. This will ensure that the data from repos can be viewed in the context of a product offering in Relyance. Consult with the legal / privacy team to define an appropriate product name for the services you define.

---

### Example Configuration file

![exampleyaml.png](https://assets.relyanceuat.xyz/images/docs/8545259841805/8547904714765.png)
In the example below, the mono source code repository is laid out as such:

```
BoutiqueApp/
 ├── src/
 │ ├── AdService/
 │ │ └── serveAds.js
 │ ├── CartService/
 │ │ ├── page.html
 │ │ └── post.html
 │ ├── CheckoutService/
 │ │ ├── page.html
 │ │ └── post.html
 │ └── index.html
 ├── FrontEnd/
 │ └── home.html
 ├── BackEnd/
 │ └── process.py
 ├── UnitTesting/
 │ └── unitTests.py
 ├── package.json
 └── README.md
```

A couple of logical items stand out:

- **Boutique App**, in this example, is an online store and the mono repo represents the source code powering the application. Therefore, “*Boutique Application*” would be considered the product.
- The **Ad Service**, **Cart Service**, **Checkout Service**, **Front End**, and **Back end** would be services of this product. These services provide an additional level of granularity from the top level product to view information in Relyance.
- **Unit testing** will likely contain mock data so the results from this directory should be excluded. This is a good example of directories that can be excluded from the scan.

This could be visualized as:

From this understanding and directory structure, we can build our ***relyance.yaml*** configuration file:

```yaml
repository: BoutiqueApp_Version_10

services:
  - service: AdService
    product:
      - Boutique Application
    tag:
      - Advertising
      - Marketing
    source:
      - src/AdService
  - service: CartService
    product:
      - Boutique Application
    tag:
      - Products
      - Inventory
    source:
      - src/CartService
  - service: CheckoutService
    product:
      - Boutique Application
    tag:
      - Payment
    source:
      - src/CheckoutService
  - service: FrontEnd
    product:
      - Boutique Application
    source:
      - FrontEnd
  - service: BackEnd
    product:
      - Boutique Application
    source:
      - BackEnd
exclude:
  - UnitTesting
```

Assign tags to provide an even more granular way to filter your services in the visualizations and the Data Map Grid.

Once this file is created, it will need to be added to the root directory of the repository.

The Relyance Source Code inspector will scan from the root of the directory.

#### More Info:

[Source Code Integration: Overview and Technical Details](/docs/integrations/source-code-integration-overview-and-technical-details/)
[Source Code Integration: Settings](/docs/integrations/source-code-integration-settings/)