API Management giriş bölgesi hızlandırıcısı için platform otomasyonu ve DevOps
Bu makalede, API Management giriş bölgesi hızlandırıcısı kullanılırken platform otomasyonu ve DevOps için tasarımla ilgili önemli noktalar ve öneriler sağlanmaktadır. Platform otomasyonu ve DevOps, kod olarak altyapı seçenekleriyle çevre dağıtımı yaklaşımınızı modernleştirme fırsatları sunar.
Platform otomasyonu ve DevOps tasarım alanı hakkında daha fazla bilgi edinin.
Tasarım konusunda dikkat edilmesi gerekenler
- Her API ekibi, güncelleştirmeleri kendi geliştirici deposundan kendi geliştirme API Management örneğine gönderebilir.
- Ağ planlaması açısından bu ne anlama geliyor?
- Diğer üretim dışı ortamlar (QA veya hazırlama gibi) ne olacak?
- Özellikle birden çok ekip aynı ürünleri kullanıyorsa, ürünlerin ve diğer varlıkların nasıl yönetileceğini veya sürüme dönüştürülmesi gerektiğini göz önünde bulundurun.
- API'ler ve ilkeler için test stratejisini göz önünde bulundurun.
Tasarım önerileri
- Üretim API Management ortamını merkezi bir ekip (örneğin, API Management yönetici ekibi) yönetir.
- API Management yapılandırmaları Resource Manager şablonları ya da eşdeğer Bicep veya Terraform şablonları olarak temsil edilir ve kod olarak altyapı zihniyetleri benimsenmelidir.
- API Management yönetim ekibi, yapılandırma değişikliklerini API Management yönetici ekibine ait bir Git deposundan (yayımcı deposu) üretim API Management ortamında yayımlar.
- Her api ekibi, yayımcı deposunu, üzerinde çalışabileceği kendi geliştirici deposuna sahip olacak şekilde çatal yapabilir.
- Her ekip, geliştirme API Management örneğinden ilgili yapıtları ayıklamak üzere Visual Studio Code için API Management APIOps veya API Management uzantısını kullanabilir. Bu yapıtlar Azure Resource Manager tabanlıdır ve API ekibinin Git deposuna işlenmelidir.
Not
API Management Git tümleştirmesini kullanmayın.
- Hizmet şablonları ve paylaşılan şablonlar ayrı depolarda olmalıdır.
- Yapıtlarda yapılan değişiklikler ayıklanan yapıtlarda yapılmalı ve git'e işlenmelidir. Bunlar bir geliştirme ortamına dağıtılmalıdır.
- Api ekipleri, merkezi ortamlara (hazırlama, üretim vb.) yükseltmek için yayımcı deposunda yaptıkları değişiklikleri birleştirmek üzere bir çekme isteği (PR) gönderebilir.
- API Management yönetici ekibi çekme isteğini doğrular.
- İdeal olarak, doğrulamaların çoğu çekme isteği gönderme işleminin bir parçası olarak otomatikleştirilmiştir.
- Kod olarak altyapı şablonları farklı bir depoda olmalı ve bir dağıtım işlem hattında dağıtılmalıdır.
- Altyapı dağıtımlarını uygulama dağıtımından ayırın. Çekirdek altyapı değişiklikleri uygulamalardan daha az sıklıkta güncelleştirilir. Her dağıtım türünü ayrı bir akış ve işlem hattı olarak değerlendirin.
- Değişiklikler onaylanıp başarıyla birleştirildikten sonra, API Management yönetim ekibi, üzerinde anlaşmaya varılan API ekibi zamanlamalarıyla eşgüdümlü olarak değişiklikleri merkezi olarak yönetilen ortama (hazırlama, üretim) dağıtabilir.
Kurumsal ölçekli varsayımlar
Aşağıda, API Management giriş bölgesi hızlandırıcısının geliştirilmesine yönelik varsayımlar yer almaktadır:
- API Management altyapısını ve arka uçlarını dağıtmak için kod olarak altyapı Bicep dosyalarını kullanma.
- İşlem hatlarını kullanarak altyapı şablonlarının dağıtımı.