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

  • Makale

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ım konusunda dikkat edilmesi gerekenler

  • 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, kodun yerel 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 kod 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 izni verilmesini ve hizmetlere erişim 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'a Kod Olarak Altyapı (IaC) kaynak dağıtımlarını kullanmayı göz önünde bulundurun. IaC, altyapıyı bildirim temelli bir modelde yönetmenize olanak sağlayarak yapılandırma çalışmalarını azaltmaya, dağıtımlar arasında tutarlılık sağlamaya ve el ile ortam yapılandırmasından kaçınmanıza yardımcı olur.

  • Azure, aşağıdakiler aracılığıyla 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 gizli olmayan bilgileri paylaşırken genel depoları kullanın.

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

Dal stratejisi

Tasarım konusunda dikkat edilmesi gerekenler

  • 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ımlama.
    • Çekme istekleri basit olmalı ve gözden geçirenlerin işlemeleri ve değişiklikleri daha verimli bir şekilde doğrulamasına yardımcı olmak için dosya sayısı en az düzeyde tutulmalıdır.
    • Gözden geçirenlerin kodu gözden geçirirken ne beklemeleri gerektiğini bilmesi için çekme isteklerinde net başlıklar ve açıklamalar olmalıdır.
    • Ç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 benimseme. 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 birleştirme çakışmaları çözülür.

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

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

  • Dal ilkelerini ayarlama:

    • 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.
    • Otomatik olarak kod gözden geçirenleri ekleyin.
    • Açıklama çözümlemesini denetleyin.

  • Çekme isteklerini tamamladığınızda konu dallarının Git geçmişini daraltmanıza olanak tanıyan 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ştirmesi tüm dosya değişikliklerini varsayılan daldaki tek bir yeni işlemeye ekler.

Otomatik derlemeler

Tasarım konusunda dikkat edilmesi gerekenler

  • 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:

    • Git'i Azure Repos. 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 testlerini eklemeyi göz önünde bulundurun.

  • Birim testlerini uygulama derleme işleminize eklemeyi göz önünde bulundurun. Azure DevOps İşlem Hattı 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ı ve 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ı kullanırken 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 ayarlayıp 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.

  • Hizmet bağlantıları veya GitHub gizli dizileri aracılığıyla Azure DevOps veya GitHub'ı 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 dizileri kullanın. Ardından derleme ve yayın işlerinizde gizli dizileri değişken olarak kullanın.

Dağıtım stratejisi

Tasarım konusunda dikkat edilmesi gerekenler

  • Sürekli Teslim (CD) kullanmayı göz önünde bulundurun. CD derlemeyi, test etmeyi, yapılandırmayı ve bir derlemeden 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ı örnekleri şunlardır:

    • Geliştirme
    • Test etme
    • QA
    • Hazırlama
    • Üretim

  • Dağıtım öncesi değişiklikleri doğrulamak ve onaylamak için stratejinizin bir parçası olarak IaC 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 şekilde 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şiklikleri önizlemek için IaC dağıtım öncesi denetimlerini ekleyin. ve kaynağın oluşturulup oluşturulmadığına, değiştirildiğine veya silindiğine ilişkin ayrıntılara bakın.

Geri alma stratejisi

Tasarım konusunda dikkat edilmesi gerekenler

  • Geri alma planı oluşturmayı göz önünde bulundurun. Dağıtımı geri almak için dağıtımın bilinen iyi bir duruma geri döndürülür ve başarısız bir dağıtımdan kurtarmanın önemli bir özelliği sağlanır.

  • Bir işlemedeki değişiklikleri geri almanız, değişiklikleri atmanız veya bir dalı önceki bir duruma sıfırlamanız gerekiyorsa Git'teki değişiklikleri geri alma seçeneğini kullanmayı göz önünde bulundurun.

Tasarım önerileri

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