Skip to content

[FEATURE] Add to fabric-cli-core skill Fabric workspace initiation best practises #218

Open
Open
[FEATURE] Add to fabric-cli-core skill Fabric workspace initiation best practises#218
Assignees
HasanAboShally
Labels
enhancementNew feature or request

Description

@kowkowhuang
OH (kowkowhuang)
opened on Apr 21, 2026

Use Case / Problem

Comprehensive approach is a UI-first, Git-backed, deployment-pipeline promoted model across DEV, TEST and PROD

High-level thoughts:

Build and initialize the DEV workspace in the Fabric UI. Once the item topology looks right, connect that workspace to Git from Workspace settings > Git integration, and the SKILL will inform Fabric write the native item definitions to the repo.

From there, use deployment pipelines to promote DEV -> TEST -> PROD. That keeps the UI as the primary design surface for initiation in DEV, while Git becomes the history, rollback, and review layer. Microsoft’s current guidance is aligned to this pattern: Git integration for source control, deployment pipelines for promotion, and separate workspaces per environment. See Get started with Git integration, CI/CD for pipelines in Data Factory, and the ALM tutorial.

Skill should also include YAML to capture run-time variables such as:

to runtime-operational parameters only, for example:

fabric_environment
timezone
source_system
semantic_refresh_enabled
landing_retention_days....etc.

Overall:

DEV is the only workspace where people make UI changes.
After UI changes, commit from the Fabric Source control pane.
TEST and PROD are deployment targets, not design workspaces.
If someone changes repo files directly, pull them back with Update from Git into DEV, validate in UI, then promote.

Tie this Skill to https://learn.microsoft.com/en-us/rest/api/fabric/core/git/initialize-connection

Proposed Solution

Create a best practise skill so the fabric-cli-core is not solely a toolset of silo'd function. It enables a process flow for best practise workspace initialisation.

Alternatives Considered

No response

Impact Assessment

  • This would help me personally
  • This would help my team/organization
  • This would help the broader fabric-cli community
  • This aligns with Microsoft Fabric roadmap items

Implementation Attestation

  • I understand this feature should maintain backward compatibility with existing commands
  • I confirm this feature request does not introduce performance regressions for existing workflows
  • I acknowledge that new features must follow fabric-cli's established patterns and conventions

Implementation Notes

No response

Activity

  1. OH (kowkowhuang)
    added
    enhancementNew feature or request
    on Apr 21, 2026
  2. microsoft-github-policy-service
    added
    needs triageThis is a new issue that needs to be triaged.
    on Apr 21, 2026

  3. microsoft-github-policy-service commented on Apr 21, 2026

    @microsoft-github-policy-service
    microsoft-github-policy-servicebot
    on Apr 21, 2026 – with Microsoft GitHub Policy Service

    Thank you for submitting this issue, OH (@kowkowhuang).
    A member of the Fabric CLI team will review your submission and provide feedback shortly.

  4. github-actions
    removed
    needs triageThis is a new issue that needs to be triaged.
    on Apr 21, 2026

  5. github-actions commented on Apr 21, 2026

    @github-actions
    github-actionsbot
    on Apr 21, 2026 – with GitHub Actions

    AI Assessment: Needs Discussion

    The request proposes a high-level "skill"—likely a bundled workflow or opinionated guide—integrating Git-based workspace initialization, parameterized YAML configuration, and pipeline-driven promotion. This is conceptually valuable for organizations using Fabric's recommended ALM pattern and aligns with Microsoft's CI/CD guidance, but raises several design questions:

    1. The CLI currently exposes granular commands but not process-level automation or "skills." Integrating a full best practice flow would require new abstractions, potentially interactive prompts, bundled templates, and guides. This diverges from Fabric CLI's current POSIX-like utility model and needs clarity on how "skill" would fit into CLI architecture and command UX.
    2. The use of runtime YAML for environment-specific parameters is valuable and technically feasible, but the scope and mapping of these parameters must be defined. It's unclear how much logic Fabric CLI should embed—should the CLI merely generate YAML and invoke APIs, or manage the end-to-end environment orchestration?
    3. Fabric's REST APIs (e.g., /core/git/initialize-connection) support some parts of the flow, but not all. For automation, pipeline promotion, and UI validation, there may be gaps or reliance on non-public APIs.
    4. Implementation requires careful attention to backward compatibility and CLI conventions, especially for workflow-level automation.

    Next Steps
    🔔 Escalated to team — This issue requires team review and has been flagged for attention.

    💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

  6. github-actions
    added
    ai:feature-triage:needs discussion
    on Apr 21, 2026

  7. github-actions commented on Apr 21, 2026

    @github-actions
    github-actionsbot
    on Apr 21, 2026 – with GitHub Actions

    🔔 @microsoft/fabric-cli-dev — This issue has been flagged by AI triage as requiring team attention. Please review the assessment above.

  8. github-actions
    added
    ai:needs team attention
    on Apr 21, 2026
  9. aviatco
    assigned
    Hasan Abo-Shally (HasanAboShally)
    on Apr 26, 2026
  10. Alon Yeshurun (ayeshurun)
    removed
    ai:needs team attention
    ai:feature-triage:needs discussion
    on May 31, 2026

  11. HasanAboShally commented on Jun 1, 2026

    @HasanAboShally
    Hasan Abo-Shally (HasanAboShally)
    on Jun 1, 2026
    Collaborator

    OH (@kowkowhuang) — appreciate the detailed write-up. You've described exactly the pattern we recommend, and I agree a skill should encode it.

    Here's my thinking on scope:

    What belongs in a skill:

    • The DEV → TEST → PROD promotion model as a documented workflow
    • YAML template for runtime parameters (environment, timezone, retention, etc.)
    • Links to the relevant REST APIs (/core/git/initialize-connection, deployment pipelines)
    • Guard rails — e.g., "only commit from DEV, never design in PROD"

    What doesn't belong in the CLI itself:

    • The CLI stays a toolbox — it won't enforce a single process flow. The skill provides the opinionated guidance; the CLI provides the commands to execute it.

    Where it'll live:

    • We're adding this to the workspace-lifecycle skill (new) rather than expanding fabric-cli-core. The core skill stays focused on CLI command usage. Lifecycle/ALM guidance gets its own skill that references the CLI commands.

    I'll tag this for our next sprint planning. If you're interested in contributing the initial YAML templates or the skill outline, we'd welcome a PR.

    One pointer while you're here: microsoft/skills-for-fabric collects Fabric skills more broadly — worth a look for patterns beyond the CLI.

  12. Alon Yeshurun (ayeshurun)
    closed this as not plannedon Jul 13, 2026
  13. Alon Yeshurun (ayeshurun)
    reopened this on Jul 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions