Welcome again to another Logic Apps Best Practices, Tips, and Tricks. In my previous blog posts, I talked about some of the essential best practices you should have while working with Azure Logic Apps. Check out these Logic App tips and tricks!
Today I’m going to speak about another important Best practice, Tips, and Tricks that you need to know before you start to develop your Logic App solutions: Choose properly your developer tools.
#12 Choose properly your developer tools
Unfortunately, like in the old days when we had a single tool to do our development: Visual Studio, at the moment, especially developing Azure Solutions, there isn’t a single and perfect tool. Instead, we have several possibilities, and we need to know before starting our development what tools we will be using based on different criteria like:
- Familiarity or preference with the tool
- Performance and productivity
- Service supportability
- Capabilities of the tool
When speaking about Logic App, we have four different tools we can or need to use:
- Azure Portal
- Visual Studio 2019
- Visual Studio 2015
- Visual Studio Code
Azure Portal
Azure Portal is without a dought the simple and quick approach for users to start developing Logic Apps Consumptions or Standard it is:
- It is pretty intuitive and fast;
- It doesn’t require any additional tools or software;
- It doesn’t require a Visual Studio License
- And almost beginner tutorials or documentation use this approach;
- It doesn’t require any additional skill – you don’t need to be familiarized with any development tool like Visual Studio – so any user profile (business user, developer, or event IT users) can start developer automation processes;
- It has better performance than all the other approaches!
- The browser reacts faster than the IE embedded in Visual Studio
- There are fewer bugs – compared to the other options also;
- And it will have faster updates because, usually this is the first place where updates will be made
However, not everything is rosy and this approach also has some limitations or disadvantages like:
- Lack of CI/CD
- By default, we can Clone the Logic App and move this copy to another resource group but then we need a lot of manual steps to rectify the Logic App to put it running successfully.
- There isn’t an excellent way to implement proper naming conventions in specific components like the API Connections
- See best practices: #11 Connectors naming convention
- Lack of proper Source code repository.
- The only thing we have is the Version history on the Azure Portal, from where we can promote a previous version to “production” but that approach has some vast limitations that I will address in the future.
- Harder to customize/parameterize certain aspects of the Logic App
In resume, for me, this approach is the best approach for:
- Doing Proofs-of-Concept
- If you have only a single “Environment” where you don’t need to worry about CI/CD processes.
Visual Studio 2019
It is a well known and familiar tool for developers, for most of them like myself their election tool! It has:
- Full CI/CD Support
- We can easily customize almost, if not everything, and we can easily use an Azure Pipelines in Azure DevOps to quickly deploy across environments or different resources
- We can easily customize/parameterize our Logic App template, parameters, and variables;
- All the connection settings will be automatically rectified in an upsert matter (create the resource if it doesn’t exist or update if it already exists)
- We can apply a Proper Naming Conventions in all components
- For example, we can easily change the default connector names to have a proper naming convention.
- We have a proper source code repository
- Visual Studio versioning and the entire development life cycle inside TFS or Git
But again, it also has some limitations or disadvantages like:
- It requires a Visual Studio License
- There are some well-known bugs, for example:
- If it reaches a certain number of actions (Logic Apps with a huge logic inside), you can no longer work inside the Visual Studio, and you need to start using the Portal or only the code view.
- If you do specific parameterizations for CI/CD, some actions will not be able the render correctly in the Visual Studio
- It would help if you still had a lot of manual configuration to apply proper naming convention or prepare the Logic App for CI/CD
- It is a tool focused on developers, so non-developers users will probably find the tool hard to use
- In the end, it has a less Performance compared to the Azure Portal
- No support for Logic Apps Standard
- Yes, you are reading correctly, at the moment there is no support for Logic App Standard in Visual Studio
- No support for Visual Studio 2022
- At the moment the Logic App extensions are available for Visual Studio 2019 (recommend version), 2017 and 2015
In resume, for me, this approach is the best approach for:
- Developing your Logic App Consumption if you have multiple “Environments” or resource groups where you need to worry about CI/CD processes.
- And it would help if you had a proper source repository
Visual Studio 2015
No, It is not a mistake. I intentionally add Visual Studi0 2015 here because it is the only tool available for us to develop our Schemas and Maps to be deployed to our Azure Integration Account.
So, no matter if you are using Azure Portal, Visual Studio 2019, and Visual Studio Code, you will always need Visual Studio 2015 if you want to use Enterprise Integration Pack (EIP), refer the official documentation here.
Visual Studio Code
And finally, for many the fashion tool: Visual Studio Code. It has like Visual Studio 2019:
- Full CI/CD Support
- We can easily customize almost, if not everything, and we can easily use an Azure Pipelines in Azure DevOps to quickly deploy across environments or different resources
- We can easily customize/parameterize our Logic App template, parameters, and variables;
- All the connection settings will be automatically rectified in an upsert matter (create the resource if it doesn’t exist or update if it already exists)
- We can apply a Proper Naming Conventions in all components
- For example, we can easily change the default connector names to have a proper naming convention.
- We have a proper source code repository
- Visual Studio versioning and the complete development life cycle inside TFS or Git
Being additionally:
- A free open-source tool
- It is a free open-source tool, which means that you don’t require any licensing;
- Full support Logic App Standard
- Full support and new Logic App Designer;
- Local project support;
- Ability to Breakpoint debugging;
- Ability to Run local our Workflows
But as always it also has some limitations or disadvantages like:
- Limit support for Logic App Consumption
- Logic App Designer is view mode only for
- Everything needs to be done manually
- No local project support
- We Can’t deploy single Stateful or stateless workflows, and we need to deploy all of them
In resume, for me, this approach is the best approach for:
- Develop your Logic App Standard if you have multiple “Environments” or resource groups where you need to worry about CI/CD processes.
- And it would help if you had a proper source repository
Stay tuned for the following Logic App Best practices, Tips, and Tricks.
