Sandbox Challenges and proposed solution

rajpalbajaj

• 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.