Geliştirme yaşam döngüsü

Geliştirme yaşam döngüsü stratejisi, otomatik giriş bölgesi oluşturma sırasında depo, dal, otomatik derlemeler, dağıtım ve geri alma stratejisi için önemli tasarım konuları ve öneriler sağlar.

Depo stratejisi

Tasarımla ilgili dikkat edilecek noktalar

  • Ekibinize kod paylaşımı ve yönetimi konusunda esneklik sağlamak için Git gibi bir sürüm denetim sistemini benimsemeyi göz önünde bulundurun.

    • Git , endüstri standardı sürüm denetim sistemidir. Bu, yerel kod kopyanızın deponun tam bir sürümü olduğu dağıtılmış bir sürüm denetim sistemidir.
  • Mono-depo ile çok depolu depo yapısını anlama.

    • Mono depo yapılarında, tüm kaynak kodu tek bir depoda bulunur.
    • Çok depolu yapılarda tüm projeler ayrı depolar halinde düzenlenir.
  • Deponuzun içeriğine uygun bir görünürlük ayarı seçin.

    • Genel depolara anonim olarak erişilebilir.
    • Özel depolar, kullanıcılara depoya erişim verilmesini ve hizmetlere erişmek için oturum açmasını gerektirir.
    • Azure DevOps Projeleri ve GitHub depoları için genel ve özel görünürlük ayarlayabilirsiniz.
  • Kaynak kodunuzla kimlerin katkıda bulunabileceğini denetlemenize ve diğer özellikleri yönetmenize yardımcı olacak depo izinlerini ayarlamayı göz önünde bulundurun.

    • Azure DevOps ve GitHub için depo izinleri ayarlayabilirsiniz.
  • Azure'a Kod Olarak Altyapı (IaC) kaynak dağıtımı kullanmayı göz önünde bulundurun. IaC, bildirim temelli bir modelde altyapıyı yönetmenize olanak sağlayarak yapılandırma çalışmalarını azaltmanıza, dağıtımlar arasında tutarlılık sağlamanıza ve el ile ortam yapılandırmasından kaçınmanıza yardımcı olur.

  • Azure, giriş bölgeleri için IaC desteği sağlar:

Tasarım önerileri

  • Git'i sürüm denetim sistemi olarak kullanın.

  • Azure Giriş Bölgeleri oluştururken özel depoları kullanma

  • Otomasyon örnekleri, genel belgeler ve açık kaynak işbirliği malzemeleri gibi uygun olmayan bilgileri paylaşırken genel depoları kullanın.

  • Bulut kaynaklarını dağıtmak, yönetmek, yönetmek ve desteklemek için IaC yaklaşımını benimseyin.

Dal stratejisi

Tasarımla ilgili dikkat edilecek noktalar

  • Ekiplerin daha iyi işbirliği yapmasına ve sürüm denetimini verimli bir şekilde yönetmesine olanak tanıyan bir dal stratejisi kullanmayı göz önünde bulundurun.

  • Dallarınız için belirli adlandırma kurallarını kullanmayı göz önünde bulundurun.

  • Kullanıcı özelliklerini denetlemek için dal izinlerini kullanmayı göz önünde bulundurun.

  • Ekiplerinizin önemli geliştirme dallarını korumasına yardımcı olmak için dal ilkelerini kullanmayı göz önünde bulundurun. Kod kalitesini zorlamaya ve yönetim standartlarını değiştirmeye yardımcı olabilecek ilkeler. Dal ilkelerine örnek olarak şunlar verilebilir:

  • Çekme isteği stratejisini benimsemek, dallarla birleştirilen kod değişikliklerinin denetimini tutmanıza yardımcı olabilir.

    • Birleştirme stratejisi tanımlayın.
    • Çekme istekleri basit olmalıdır ve gözden geçirenlerin işlemeleri ve değişiklikleri daha verimli bir şekilde doğrulamalarına yardımcı olmak için dosya sayısı en az düzeyde tutulmalıdır.
    • Çekme isteklerinin açık başlıkları ve açıklamaları olmalıdır, böylece gözden geçirenler kodu gözden geçirirken ne beklemeleri gerektiğini bilmelerini sağlar.
    • Çekme isteği şablonlarını kullanabilirsiniz.
    • Çekme istekleri tamamlandıktan sonra kaynak dalları silebilirsiniz; bu da size daha fazla denetim ve daha iyi dal yönetimi sağlar.

Tasarım önerileri

  • Geliştiricilerin tek bir dala taahhüt ettiği gövde tabanlı bir geliştirme modelini benimseyin. Bu model sürekli tümleştirmeyi kolaylaştırır. Tüm özellik işleri gövdede yapılır ve işleme gerçekleştiğinde tüm birleştirme çakışmaları çözülür.

  • Ekiplerinizin, yapılan işi tanımlamak için dallar için tutarlı adlandırma kuralları tanımlamasını ve kullanmasını sağlayın.

  • Git deponuzun bir dalında kimlerin kod okuyup güncelleştirebileceğini denetlemek için izinleri ayarlayın. Tek tek kullanıcılar ve gruplar için izinleri ayarlayabilirsiniz.

  • Dal ilkelerini ayarlayın:

    • Ana dalda dal birleştirmeleri için çekme isteklerinin kullanılmasını zorunlu kılar.
    • Çekme istekleri için en az sayıda gözden geçiren gerektir.
    • Tüm onay oylarını kaldırmak için tüm onay oylarını sıfırlayın, ancak bir kaynak dal değiştiğinde reddetmek veya beklemek için oyları koruyun.
    • Kod gözden geçirenleri otomatik olarak ekleyin.
    • Açıklama çözümlemesini denetleyin.
  • Çekme isteklerini tamamladığınızda konu dallarının Git geçmişini daraltmanızı sağlayan birleştirme stratejisi olarak squash ayarlayın. Bir konu dalındaki her işlemeyi varsayılan dalın geçmişine eklemek yerine, squash birleştirme tüm dosya değişikliklerini varsayılan daldaki tek bir yeni işlemeye ekler.

Otomatik derlemeler

Tasarımla ilgili dikkat edilecek noktalar

  • Sürekli Tümleştirme (CI) uygulamayı göz önünde bulundurun. CI, tüm geliştirici kodlarını düzenli bir zamanlamaya göre merkezi bir kod tabanında birleştirmeyi ve standart derlemeleri ve test işlemlerini otomatik olarak yürütmeyi içerir.

  • CI tetikleyicilerini kullanmayı göz önünde bulundurun:

    • Azure Repos Git. Ci derlemesini çalıştırmak için dalları, yolları ve etiketleri tetikleyici olarak yapılandırabilirsiniz.
    • GitHub. CI derlemesini çalıştırmak için dalları, yolları ve etiket tetikleyicilerini yapılandırabilirsiniz.
  • Söz dizimini doğrulamak için derleme işleminize IaC birim testleri eklemeyi göz önünde bulundurun.

  • Uygulama derleme işleminize birim testleri eklemeyi göz önünde bulundurun. Azure DevOps Pipeline için kullanılabilir görevleri gözden geçirin.

  • Azure'a bağlantıları yönetmek için Azure DevOps hizmet bağlantılarını veya GitHub gizli dizilerini kullanın. Her bağlantının Azure kaynaklarına doğru ayrıcalık erişimi olmalıdır.

  • Parolalar, API anahtarları, sertifikalar gibi hassas bilgileri depolamak ve yönetmek için Azure Key Vault gizli dizilerini kullanmayı göz önünde bulundurun.

  • Azure DevOps aracıları şirket içinde veya Microsoft tarafından barındırılabilir.

    • Microsoft tarafından barındırılan aracıları kullandığınızda bakım ve yükseltme işlemleri sizin için yapılır. Derleme işi her çalıştırıldığında yeni bir sanal makine oluşturulur.
    • Derleme işlerini çalıştırmak için şirket içinde barındırılan aracıları kendiniz ayarlar ve yönetirsiniz.

Tasarım önerileri

  • Bir ekip üyesi sürüm denetiminde değişiklikleri her işlediğinde kod derlemelerini ve testlerini otomatikleştirmek için CI kullanın.

  • Derleme işleminizin bir parçası olarak IaC ve uygulama kodu için birim testleri ekleyin.

  • Mümkünse, her işlem hattı çalıştırması için yalıtım ve temiz bir VM sunduğundan şirket içinde barındırılan havuzlar yerine Microsoft tarafından barındırılan havuz kullanın.

  • Azure DevOps veya GitHub'ı hizmet bağlantıları veya GitHub gizli dizileri aracılığıyla Azure'a bağladığınızda, yalnızca gerekli kaynaklara erişebilmeleri için kapsamı her zaman tanımladığınızdan emin olun.

  • Kimlik bilgileri (sanal makinenin kullanıcı parolaları), sertifikalar veya anahtarlar gibi hassas bilgileri sabit kodlamaktan kaçınmak için Key Vault gizli dizilerini kullanın. Ardından derleme ve yayın işlerinizde değişken olarak gizli dizileri kullanın.

Dağıtım stratejisi

Tasarımla ilgili dikkat edilecek noktalar

  • Sürekli Teslim (CD) kullanmayı göz önünde bulundurun. CD derlemeyi, test etmeyi, yapılandırmayı ve bir derlemeden bir ortama dağıtmayı içerir.

  • Ortamları kullanmayı göz önünde bulundurun. Ortamlar, bir teslim işinden kaynak koleksiyonunu hedeflemenizi sağlar. Yaygın ortam adları şunlardır:

    • Geliştirme
    • Test etme
    • QA
    • Hazırlama
    • Üretim
  • Dağıtım öncesi değişiklikleri doğrulamak ve onaylamak için IaC'yi stratejinizin bir parçası olarak kullanmayı göz önünde bulundurun.

Tasarım önerileri

  • Kodu otomatik olarak oluşturarak, test ederek ve üretim benzeri ortamlara dağıtarak kodun her zaman dağıtıma hazır olduğundan emin olmak için CD kullanın. Kod hatalarını olabildiğince erken algılamanıza yardımcı olan ve düzgün test edilmiş güncelleştirmeleri hızla yayımlayabilmenizi sağlayan tam bir CI/CD tümleştirmesi oluşturmak için sürekli teslim ekleyin.

  • Dağıtım stratejinizin bir parçası olarak ortamları kullanın. Ortamlar aşağıdaki gibi avantajlar sağlar:

    • Dağıtım geçmişi
    • İşlemelerin ve iş öğelerinin izlenebilirliği
    • Tanılama kaynağı durumu
    • Güvenlik
  • Değişikliklerin önizlemesini görüntülemek ve kaynağın oluşturulup oluşturulmadığını, değiştirilip değiştirilmediğini veya silindiğini görmek için IaC ön dağıtım denetimlerini ekleyin.

Geri alma stratejisi

Tasarımla ilgili dikkat edilecek noktalar

Tasarım önerileri

  • Kaydedilmiş dosyalarda yapılan değişiklikleri geri almanız, kaydedilmemiş değişiklikleri atabilmeniz veya bir dalı önceki bir duruma sıfırlamanız gerektiğinde Git'te değişiklikleri geri alma kullanımını benimseyin.