@Anonymous Developer: If you want to rerun an ExecutePipeline activity, you should invoke the pipeline directly instead of trying to trigger the ExecutePipeline activity from another pipeline. Unless of course ExecutePipeline fails to spin off a pipeline, in which case, you can (1) rerun ExecutePipeline activity or (2) manually trigger the target pipeline.
@Dav_id: From Sunil - “With Flexible Server, you can manually stop the database and only pay for storage provisioned, and not the compute. Azure SQL Serverless indeed provides more capabilities such as auto scale and we will consider this for the future.”
When we talk about CI/CD, we're really talking about several related processes: Continuous integration, continuous delivery, and continuous deployment.
Continuous integration. Code changes are frequently merged into the main branch. Automated build and test processes ensure that code in the main branch is always production-quality.
Continuous delivery. Any code changes that pass the CI process are automatically published to a production-like environment. Deployment into the live production environment may require manual approval, but is otherwise automated. The goal is that your code should always be ready to deploy into production.
Continuous deployment. Code changes that pass the previous two steps are automatically deployed into production.
The requirement for RBAC reader role no longer applies to the variety of tools & frameworks that integrate with ADLS Gen2. This means that you can choose coarse-grained access mechanisms via RBAC or fine-grained access via ACL or a combination of both.
Access control via ACLs-only does require special handling is some tools (eg. for Azure Storage Explorer you need the v1.9+ to ‘mount’ an ADLS Gen2 container as the user will not be able to browse to that account).
I am able to confirm that Azure SQL Data Warehouse’s Polybase capability does indeed work in being able to reference data in ADLS Gen2 using the system-assigned MSI when that MSI only has ACL access and not RBAC access.
There are 2 things to consider when applying ACLs in ADLS Gen2:
1. Irrespective on where the MSI is granted read ‘R’ and/or write ‘W’ access, the principal MUST have execute ‘X’ permission from the root directory all the way down to the data directory. This allows the MSI to traverse the directory structure and will fail without this permission.
2. The ‘Principal ID’ of the MSI must be the guid value specified in the ACL. This can be obtained using the Powershell ‘Get-AzSqlServer’ cmdlet.