Platformautomatisering en DevOps voor de API Management landingszoneversneller
Dit artikel bevat ontwerpoverwegingen en aanbevelingen voor platformautomatisering en DevOps bij gebruik van de API Management landingszoneversneller. Platformautomatisering en DevOps bieden mogelijkheden om uw benadering van omgevingsimplementatie te moderniseren met opties voor infrastructuur als code.
Meer informatie over platformautomatisering en DevOps-ontwerpgebied .
Overwegingen bij het ontwerpen
- Elk API-team kan updates van hun eigen opslagplaats voor ontwikkelaars pushen naar hun eigen ontwikkel-API Management-exemplaar.
- Wat betekent dit vanuit het perspectief van netwerkplanning?
- Hoe zit het met andere niet-productieomgevingen (zoals QA of fasering)?
- Overweeg hoe producten en andere entiteiten moeten worden beheerd of versiebeheer, met name als meerdere teams dezelfde producten gebruiken.
- Overweeg de teststrategie voor API's en beleidsregels.
Ontwerpaanbeveling
- Een centraal team (bijvoorbeeld een API Management-beheerdersteam) beheert de productie-API Management-omgeving.
- API Management configuraties worden weergegeven als Resource Manager-sjablonen of equivalente Bicep- of Terraform-sjablonen, en een infrastructuur-als-code-instelling moet worden omarmd.
- Het API Management-beheerdersteam publiceert configuratiewijzigingen naar de productie-API Management-omgeving vanuit een Git-opslagplaats (opslagplaats voor uitgevers) die eigendom is van het API Management-beheerdersteam.
- Elk afzonderlijk API-team kan de opslagplaats van de uitgever splitsen om een eigen opslagplaats voor ontwikkelaars te hebben waaruit kan worden gewerkt.
- Elk team kan de API Management APIOps of de API Management-extensie voor Visual Studio Code gebruiken om de relevante artefacten te extraheren uit hun ontwikkelexemplaren API Management. Deze artefacten zijn gebaseerd op Azure Resource Manager en moeten worden doorgevoerd in de Git-opslagplaats van het API-team.
Notitie
Gebruik de API Management Git-integratie niet.
- Servicesjablonen en gedeelde sjablonen moeten zich in afzonderlijke opslagplaatsen bevindt.
- Wijzigingen in artefacten moeten worden uitgevoerd in de geëxtraheerde artefacten en vervolgens worden doorgevoerd in Git. Deze moeten worden geïmplementeerd in een ontwikkelomgeving.
- Om te promoveren naar de gecentraliseerde omgevingen (fasering, productie, enzovoort), kunnen API-teams een pull-aanvraag (PR) indienen om hun wijzigingen samen te voegen met de opslagplaats van de uitgever.
- Het API Management-beheerdersteam valideert de pull-aanvraag.
- In het ideale scenario worden de meeste validaties geautomatiseerd als onderdeel van het indienen van een pull-aanvraag.
- De sjablonen voor infrastructuur als code moeten zich in een andere opslagplaats bevinden en in een implementatiepijplijn worden geïmplementeerd.
- Scheid de implementatie van de infrastructuur van de toepassing. De kerninfrastructuur verandert minder vaak dan toepassingen. Behandel elk type implementatie als een afzonderlijke stroom en pijplijn.
- Nadat de wijzigingen zijn goedgekeurd en samengevoegd, kan het API Management-beheerdersteam de wijzigingen implementeren in de centraal beheerde omgeving (fasering, productie) in coördinatie met overeengekomen API-teamschema's.
Veronderstellingen op ondernemingsniveau
Hier volgen veronderstellingen die zijn meegenomen in de ontwikkeling van de API Management landingszoneversneller:
- Bicep-bestanden voor infrastructuur als code gebruiken om API Management infrastructuur en back-ends te implementeren.
- Implementatie van infrastructuursjablonen met behulp van pijplijnen.