feat: optimized Deployment workflow by separating jobs into individual workflows

[Vamshi-Microsoft]

Purpose

This pull request introduces a new modular and reusable GitHub Actions workflow system for deployment, testing, and cleanup on both Linux and Windows environments. The changes replace previous monolithic workflows with a set of orchestrated jobs, improving maintainability, configurability, and automation for Azure resource management and CI/CD processes.

Reusable Workflow Architecture:

• Added a central workflow orchestrator (deployment-orchestrator.yml) that coordinates deployment, Docker image building, end-to-end testing, notifications, and cleanup, supporting both Linux and Windows runners.
• Created specialized job workflows for configuration display (job-display-configuration.yml) and resource cleanup (job-cleanup-deployment.yml), allowing for targeted and maintainable job definitions. [1] [2]

Environment and Configuration Improvements:

• Enhanced workflow inputs to support flexible deployment options (Azure location, resource group, WAF, EXP, Docker build, cleanup, E2E test suite selection, and use of existing web app URLs). [1] [2]
• Implemented logic to auto-enable EXP when relevant resource IDs are provided, ensuring correct configuration without manual intervention.

Deployment and Cleanup Automation:

• Automated resource group cleanup with optimized asynchronous deletion and summary reporting, reducing manual effort and improving transparency of cleanup status.
• Provided clear summary outputs for each job, including configuration, deployment, and cleanup status, enhancing traceability in the CI/CD pipeline. [1] [2]

Platform Support:

• Introduced separate entry-point workflows for Linux (deploy-linux.yml) and Windows (deploy-windows.yml), each leveraging the orchestrator for platform-specific deployment flows. [1] [2]

Testing and Notification Integration:

• Integrated end-to-end test automation and notification jobs, triggered conditionally based on deployment and configuration, ensuring robust validation and reporting.

These changes collectively modernize the deployment pipeline, making it more modular, maintainable, and easier to extend for future requirements.

Does this introduce a breaking change?

• Yes
• No

Golden Path Validation

• I have tested the primary workflows (the "golden path") to ensure they function correctly without errors.

Deployment Validation

• I have validated the deployment process successfully and all services are running as expected with this change.