|
| 1 | +[](https://dev.azure.com/apim-devops/ARM-template-generator/_build/latest?definitionId=1?branchName=master) |
| 2 | + |
| 3 | +# Azure API Management DevOps Example |
| 4 | + |
| 5 | +This repository contains examples and tools to help you achieve API DevOps with Azure API Management. |
| 6 | + |
| 7 | +## Background |
| 8 | + |
| 9 | +Organizations today often have multiple deployment environments (e.g., development, QA, production) and use separate API Management (APIM) instances for each environment. In some cases, those APIM instances are shared by a number of API development teams, each responsible for one or more APIs. It becomes a challenge for organizations to automate deployment of APIs into a shared environment without interference between the teams and/or impact on API consumers. |
| 10 | + |
| 11 | +In this repository, we propose an approach for the problem along with examples and tools to implement the solution. |
| 12 | + |
| 13 | +## API DevOps with API Management |
| 14 | + |
| 15 | +The proposed approach is shown in the below picture. |
| 16 | + |
| 17 | + |
| 18 | + |
| 19 | +In this example, there are two deployment environments: _Development_ and _Production_, each environment has its own APIM instance. _API developers_ have access to the _Development_ instance and can use it for developing and testing their APIs. The _Production_ instance is managed by a designated team called the _API publishers_. |
| 20 | + |
| 21 | +The key in this proposed solution is to keep all your APIM configurations in Azure Resource Manager (ARM) templates under your SCM systems. In this example, we use GIT. There is a _Publisher repository_ that contains all the configurations of the _Production_ instance. _API developers_ can fork and clone the _Publisher repository_ and then start working on their APIs in their own repository. |
| 22 | + |
| 23 | +There are three types of ARM templates: the _Service template_ contains all the configurations related to the APIM instance (e.g., sku type, custom URL). The _Shared templates_ contain shared resources (e.g., groups, products). For each API, there is an _API template_ that contains all the configurations related to the API and its sub-resources (e.g., API definition, operations, policies). |
| 24 | + |
| 25 | +Finally, The _Master template_ ties everything together by linking to all templates and deploy them in order. Therefore, if you want to deploy everything to an APIM instance, you can simply deploy the _Master template_. A beautiful thing is that each template can also be deployed individually. For example, if you just want to deploy a single API. |
| 26 | + |
| 27 | +_API developers_ normally work with Open API (aka., Swagger) files for defining their APIs. One challenge for them is authoring the _API templates_, which might be an error-prone task for people not familiar with ARM template formats. Therefore, we will create and open source an **ARM template generator** to help you generate _API templates_ based on Open API (aka., Swagger) files and policy files. Basically, the generator will extract your API and operation definitions from an Open API file and insert them into an ARM template in the proper format. It will also extract policies from an XML file and inline the policies into the template. With this tool, _API developers_ can continue focusing on the formats they are familiar with. |
| 28 | + |
| 29 | +If you already have APIs published by APIM, or if you prefer using the Admin UX for configuring your APIs, we will also provide a **second ARM template generator** to help you generate _API templates_ by extracting configurations from an existing APIM instance. Likewise, this generator will also be open sourced. |
| 30 | + |
| 31 | +When _API developers_ finish develop and test an API, and have generated the _API template_ for it, they can submit a pull request to merge the changes back to the _Publisher repository_. _API publishers_ can validate the pull request to make sure the changes are safe and compliant to the corporate standards. Most of the validations can be automated as part of the CI/CD pipeline. |
| 32 | + |
| 33 | +Once the changes are merged successfully, then _API publishers_ can deploy them to the _Production_ instance either on schedule or on request. |
| 34 | + |
| 35 | +With this approach, it is easy to migrate changes from one environment to another. Also, since different API development teams will be working on different sets of API templates and files, it also prevents them from colliding with each other. |
| 36 | + |
| 37 | +We have provided an [example](Example.md) on how to use this approach and deploy using the Azure CLI. |
| 38 | + |
| 39 | +We realize our customers bring a wide range of engineering cultures and existing automation solutions. The approach proposed here is not meant to be a one-size-fits-all solution. That's the reason we created this repository and open sourced everything, so that you can extend and custom the solution. |
| 40 | + |
| 41 | +If you have any questions or feedback, please raise issues in the repository or email us at apimgmt at microsoft dotcom. We also started an [FAQ page](./FAQ.md) to answer most common questions. |
| 42 | + |
| 43 | +## License |
| 44 | + |
| 45 | +This project is licensed under [the MIT License](LICENSE) |
| 46 | + |
| 47 | +This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments. |
| 48 | + |
| 49 | +## Contributing |
| 50 | + |
| 51 | +This project welcomes contributions and suggestions. Most contributions require you to agree to a |
| 52 | +Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us |
| 53 | +the rights to use your contribution. For details, visit https://cla.microsoft.com. |
| 54 | + |
| 55 | +When you submit a pull request, a CLA-bot will automatically determine whether you need to provide |
| 56 | +a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions |
| 57 | +provided by the bot. You will only need to do this once across all repos using our CLA. |
| 58 | + |
| 59 | +This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). |
| 60 | +For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or |
| 61 | +contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments. |
0 commit comments