- Repo Promotion: When you promote a "Repository", all objects within it are promoted, regardless of whether they've been modified. This leads to unnecessary updates in production, potentially causing:
- Unnecessary "Modified" Dates: Objects that haven't changed still show a new "last updated" date, making it harder to track true changes.
- Increased Risk: Every "promotion" becomes a larger operation, increasing the potential for unintended side effects or regressions, even on unchanged objects
- Audit Trails: It requires manual record keeping to identify what actually changed in a given deployment.
- Current Workaround: To mitigate this, we are forced to create separate repos for individual (or tightly coupled small groups of) objects. While this limits the scope of promotion, it leads to:
- Management Overhead: A proliferation of repos becomes difficult to manage, especially for interdependent objects.
- Broken Dependencies: If objects are truly connected and in separate repos, managing their synchronized promotion becomes a nightmare.
Proposed Solution (and its Benefits):
Would like to advocate a more intelligent, change-aware promotion mechanism, similar to how version control systems (like Git/Bitbucket) handle branches and commits. Here's a summary of your proposal and its benefits:
- Intelligent Committing to Repo:
- Current State: When committing a repo, it updates all selected objects.
- Desired State: Internally, the system should identify only the changed objects among those saved in the repository. Only these changed objects should be updated within the repo itself.
- Branching for Changed Objects:
- Current State: (Implicitly, the entire repo is the "unit" of change.)
- Desired State: In parallel with the intelligent commit, a new "branch" (or similar versioning construct) should be created. This branch would contain only the truly changed objects. This is analogous to a feature branch in Git where you work on specific changes.
- Targeted Promotion:
- Current State: When the repo is promoted, all objects in the repo are promoted to production.
- Desired State: The promotion process should target this newly created branch containing only the changed objects. This ensures that:
- Only Changed Objects are Modified: Only the objects that truly had updates are touched in the production environment.
- Unchanged Objects Retain State: Unchanged objects in production would retain their original version and "last updated" dates, providing clearer historical lineage.
- Reduced Risk: Smaller, more focused deployments inherently carry less risk.
- Clearer Audit Trails: It becomes much easier to see what actually changed in a given deployment.
