Build artifacts (appPackage, ARM/bicep, Azure AD Manifest) which can be used in CD pipeline

[JohanKlijn]

Is your feature request related to a problem? Please describe. Not able to integration Teams Toolkit with our CI-CD patterns and practices

Describe the solution you'd like First of all, I really like the Teams Tools kit. I allows you to easily build and manually deploy application from Visual Studio Code. The part that doesn’t feel good, is the way CI-CD is done/suggested. In the manual (https://github.com/OfficeDev/TeamsFx/blob/main/docs/cicd_insider/README.md) there are a couple of thing noted:

• The provision step is not included in the CD template as it's usually executed only once. In my opinion this is not true. The Teams Toolkit is using bicep/ARM, so Infrastructure as code (IaC). Those files are changed during development cycles. Meaning deployment will probably happens more than once and you also want to have this automated.

• Please remember to commit after provisioning (results of provisioning will be deposited inside the .fx folder). A commit after provisioning means a new build is triggered, which will triggers the whole CI/CD pipeline again. It also feels conceptual strange, that “code” is change, after are CD pipeline.

Another “issue” in my opinion is that the publishing part (Azure resources, Teams app) requires the full repo of the Teams app/ In Azure DevOps you normally have a build pipeline and a release pipeline. The build pipeline is normally triggered on every commit, but the release pipeline is often a manual process, because someone in the organization needs to approve the deployment (to production). My suggestion would be: the Teams Toolkit creates the following artifacts (in de CI pipeline) during a build:

• Teams app (appPackage)
• Azure AD manifest (the transpiled version of aad.template.json)
• Bicep/arm files (The transpiled versions, so without all the parameters like
• Build of your react application.

The output of the build, can then be used in the CD pipeline.

Describe alternatives you've considered

Additional context

[ghost]

Thank you for contacting us! Any issue or feedback from you is quite important to us. We will do our best to fully respond to your issue as soon as possible. Sometimes additional investigations may be needed, we will usually get back to you within 2 days by adding comments to this issue. Please stay tuned.

[jidddddd]

Hi @JohanKlijn , appreciate the feedback! Better deployment experience is an area we are actively working on, we will provide more update once we've made more progress.

In the meantime, could you share with us how your team currently use CI/CD with teamsfx to work around these issues or are you using teamsfx's built in features?

[JohanKlijn]

Hi @jidddddd ,

Currently we don’t use the Teams Toolkit at all in our CI/CD pipeline, because of a couple of reasons. We have different Azure environments (Development and Production). Developers are only allowed to create resources manually (for example using the Teams Toolkit) in the Development environment and in production every change should be made through our CD pipeline. The initial provisioning of the resources using Teams Toolkit creates and creates the states (state.environment.json) in the project folder. The state is required for the next times when you provision your resources, for example to use the same Azure AD App Registration. Because of our policies we can only provision resource in the CD pipeline, meaning the initial provisions should also happen in the CD pipeline, meaning a commit of the states files must be done in the CD pipeline, which of course is something you don’t want. If I am honest, I think the tool is too much in during the provisioning and there should be an intermediate step, so it can support CI/CD. I do like the template’s (config.dev.json, aad.template.json, manifest.template.json), so can define generic data in a single file and date per environment in the config.environment.json.

My suggestion would be that teamsfx is doing the following:

• Keeps using the templates (without the dependency on the states).
• Be able to “transpile’ the template in the CD pipeline.
• Be able to use the “transpiled” templates to deploy your resource in the CD pipeline.

Just like ARM Templates you should be able to pass variables in the CD pipeline when transpile/deploy, so you can use DevOps pipeline variable to replace variables in the templates. For example, we always add a postfix to resources in Azure which specifies the environment (like D01, T01, P01).

I do understand there is one challenge, and that’s the Azure ADD App Registration ID, you don’t know the Client ID, until it’s created. So in our case, that should be a one-time only manual step, and the client ID would be a variable in our CD pipeline.

So in short, I think the Teams Toolkit should separate the “transpilation” and provisioning in two steps, and don’t make use of state (of resource being deployed), because state always makes things more complex. The idea of ARM Templates is more or less, what I would expect. You can define upfront (using templates) what you want, and you can use them for multiple environment using parameters during provisioning (CD pipeline).

I understand it’s a difficult topic and hard to explain, so if required we can always have a Teams meeting.

[jidddddd]

@JohanKlijn, thanks for the detailed write up, we'd love to chat with you! I can't post it here, but feel free to reach out to my profile contact.

[ThomasPe]

I just wanted to 2nd this request as it breaks the GitHub flow. As a short-term fix I think some insights on how to run just the bicep files would be nice.

[jidddddd]

Hi @ThomasPe, there is an upcoming release that should help with this issue, I'll ping back here once the release is out