Skip to content
This repository has been archived by the owner on Mar 18, 2024. It is now read-only.

docs(dr): propose changes to aliasfy package #1418

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions decision records/deployments/003-aliasfy-eliminate-redundancy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# Eliminating Redundancy in Aliasified Source and Data Packages

* Status: Proposed
* Deciders: Azlam, Vu, Zhebin
* Date:

## Context and Problem Statement

The current implementation of aliasified packages in sfpowerscripts supports a 'default' directory and environment-specific directories (e.g., `dev`, `sit`, `st`). While this structure ensures flexibility, it introduces redundancy. The contents of the 'default' directory often have to be duplicated across multiple environment-specific directories. This leads to increased maintenance complexity and greater risk of errors.

Existing Structure:

```
src-env-specific-alias-post
└── main
├── default
| └── <contents>
├── dev
│ └── <contents>
├── sit
│ └── <contents>
└── st
└── <contents>
```

## Decision

To alleviate the redundancy and error-prone nature of the current approach, the proposal is to introduce a layer of inheritance for aliasified packages.

Revised Structure:

```
src-env-specific-alias-post
└── main
├── default
| └── <base_contents>
├── dev
│ └── <override_contents>
├── sit
│ └── <override_contents>
└── st
└── <override_contents>
```

- sfpowerscripts will continue to try to match the `alias` as it does today.
- If an alias matches, the contents in the `<alias>` directory will be merged with the contents in the `default` directory.
- If there's a conflict, the `<alias>` directory takes precedence.
- If the alias isn't found, it will fall back to the `default` directory.
- If neither is found, an error will be thrown.


- To ensure the changes do not disrupt exising users of the aliasfy feature, this enhanced aliasfy package feature has to be explictly enabled as 'aliasfyv2'in the sfdx-project.json
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do it the other way around? as in you need to specify V1 if you want to remain on the current thing, so that in the future we can just deprecate V1 without having to maintain this flag?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that idea, but that means if the users don't see the announcement, they might inadvertently deploy 'default' components into production.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @azlam-abdulsalam . We have to be backward compatible. I bet most of the org user :latest image (like we at K).

I would suggest being more specific on the name of this enhancement as it provides certain features, not many - inheritance.

Options:

  • alisifiedInheritence
  • aliasfyInheritence
  • enableAlisifiedInheritence
  • enableAlisifyInheritence

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or may be better, we treat it as a default behaviour for all package? @ruslan-kurchenko @rody , if it sees an aliasified folder, it will start doing this behaviour across any source package

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@azlam-abdulsalam when you refer to all packages, do you mean that some repos would have like a core-crm source package folder and within that have specific dev, sit, uat alias packages inside that package?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@crazynammer that's correct, any packages can have env specific overrides, but at the same time, this idea of aliasified envs is conflicting with our notion of detaching tests from dedicated environments,



By implementing this inheritance mechanism, we reduce redundancy, simplify maintenance, and minimize the scope for errors.