Kaynak Denetimi (Azure ile Real-World Cloud Apps Oluşturma)

  • Makale

Tarafından Rick Anderson, Tom Dykstra

Fix It Project'i indirin veya E-kitap indirin

Azure ile Gerçek Dünya Bulut Uygulamaları Oluşturma e-kitabı, Scott Guthrie tarafından geliştirilen bir sunuyu temel alır. Bulut için web uygulamalarını başarıyla geliştirmenize yardımcı olabilecek 13 desen ve uygulama açıklanmaktadır. E-kitap hakkında bilgi için ilk bölüme bakın.

Kaynak denetimi yalnızca ekip ortamları için değil tüm bulut geliştirme projeleri için gereklidir. Geri alma işlevi ve otomatik yedeklemeler olmadan kaynak kodu ve hatta Word bir belgeyi düzenlemeyi düşünmezsiniz ve kaynak denetimi, bu işlevleri proje düzeyinde size bir sorun olduğunda daha da fazla zaman kazandırabilecekleri bir proje düzeyinde sunar. Bulut kaynağı denetim hizmetleriyle artık karmaşık kurulum konusunda endişelenmeniz gerekmez ve en fazla 5 kullanıcı için ücretsiz Azure Repos kaynak denetimi kullanabilirsiniz.

Bu bölümün ilk bölümünde göz önünde bulundurulması gereken üç temel en iyi yöntem açıklanmaktadır:

Bölümün geri kalanında Visual Studio, Azure ve Azure Repos bu desenlerin bazı örnek uygulamaları verilmiştir:

Otomasyon betiklerini kaynak kod olarak ele alın

Bir bulut projesi üzerinde çalışırken işleri sık sık değiştiriyor ve müşterileriniz tarafından bildirilen sorunlara hızlı bir şekilde tepki vermek istiyorsunuz. Her Şeyi Otomatikleştirme bölümünde açıklandığı gibi, hızlı yanıt vermek için otomasyon betiklerinin kullanılması gerekir. Ortamınızı oluşturmak, ortamınıza dağıtmak, ölçeklendirmek vb. için kullandığınız tüm betiklerin uygulama kaynak kodunuzla eşitlenmiş olması gerekir.

Betikleri kodla eşitlenmiş durumda tutmak için bunları kaynak denetim sisteminizde depolayın. Daha sonra, geliştirme kodundan farklı olan üretim kodundaki değişiklikleri geri almanız veya hızlı bir düzeltme yapmanız gerekirse, hangi ayarların değiştiğini veya hangi ekip üyelerinin ihtiyacınız olan sürümün kopyalarına sahip olduğunu izlemeye çalışmak için zaman kaybetmenize gerek yoktur. İhtiyacınız olan betiklerin ihtiyacınız olan kod tabanıyla eşitlenmiş olduğundan ve tüm ekip üyelerinin aynı betiklerle çalıştığından emin olabilirsiniz. Daha sonra üretime veya yeni özellik geliştirmeye yönelik sık erişimli bir düzeltmenin test ve dağıtımını otomatikleştirmeniz gerekip gerekmediğine bakılmaksızın, güncelleştirilmesi gereken kod için doğru betiği elde edersiniz.

Gizli dizileri iade etme

Kaynak kod deposuna genellikle çok fazla kişi erişebilir ve parolalar gibi hassas veriler için uygun şekilde güvenli bir yer olabilir. Betikler parola gibi gizli dizileri kullanırsa, bu ayarları kaynak koda kaydedilmemeleri için parametreleştirin ve gizli dizilerinizi başka bir yerde depolayın.

Örneğin Azure, yayımlama profillerinin oluşturulmasını otomatikleştirmek için yayımlama ayarlarını içeren dosyaları indirmenize olanak tanır. Bu dosyalar, Azure hizmetlerinizi yönetme yetkisine sahip kullanıcı adlarını ve parolaları içerir. Yayımlama profilleri oluşturmak için bu yöntemi kullanırsanız ve bu dosyaları kaynak denetimine iade ederseniz, deponuza erişimi olan herkes bu kullanıcı adlarını ve parolalarını görebilir. Parola şifrelenmiş olduğundan ve varsayılan olarak kaynak denetimine dahil edilmeyen bir .pubxml.user dosyasında olduğundan, parolayı yayımlama profilinin kendisinde güvenle depolayabilirsiniz.

DevOps iş akışını kolaylaştırmak için kaynak dalları yapılandırma

Deponuzda dalları uygulama şekliniz hem yeni özellikler geliştirmenizi hem de üretimdeki sorunları çözmenizi etkiler. Burada, çok sayıda orta ölçekli ekibin kullandığı bir desen yer alır:

Kaynak dal yapısı

Ana dal her zaman üretimdeki kodla eşleşir. Ana öğesinin altındaki dallar, geliştirme yaşam döngüsünün farklı aşamalarına karşılık gelir. Geliştirme dalı, yeni özellikleri uyguladığınız yerdir. Küçük bir ekip için yalnızca ana ve geliştirmeniz olabilir, ancak genellikle insanların geliştirme ve ana arasında bir hazırlama dalı olması önerilir. Bir güncelleştirme üretime taşınmadan önce son tümleştirme testi için hazırlamayı kullanabilirsiniz.

Büyük takımlar için her yeni özellik için ayrı dallar olabilir; daha küçük bir ekip için herkesin geliştirme dalını denetlemesini isteyebilirsiniz.

Her özellik için bir dalınız varsa, A Özelliği hazır olduğunda kaynak kodu değişikliklerini geliştirme dalı ile diğer özellik dalları arasında birleştirirsiniz. Bu kaynak kodu birleştirme işlemi zaman alabilir ve özellikleri ayrı tutarken bu çalışmayı önlemek için bazı takımlar özellik geçişleri ( özellik bayrakları olarak da bilinir) olarak adlandırılan alternatif bir uygulama uygular. Bu, tüm özelliklerin tüm kodunun aynı dalda olduğu, ancak kodda anahtarları kullanarak her özelliği etkinleştirdiğiniz veya devre dışı bırakabileceğiniz anlamına gelir. Örneğin, Özellik A'nın Düzelt uygulama görevleri için yeni bir alan olduğunu ve Özellik B'nin önbelleğe alma işlevi eklemiş olduğunu varsayalım. Her iki özelliğin kodu da geliştirme dalında olabilir, ancak uygulama yalnızca bir değişken true olarak ayarlandığında yeni alanı görüntüler ve yalnızca farklı bir değişken true olarak ayarlandığında önbelleğe almayı kullanır. Özellik A yükseltilmeye hazır değilse ancak Özellik B hazırsa, Özellik A düğmesi kapalı ve Özellik B düğmesi açık durumdayken kodun tümünü Üretim'e yükseltebilirsiniz. Ardından Özellik A'yı tamamlayabilir ve daha sonra kaynak kodu birleştirmeden yükseltebilirsiniz.

Özellikler için dallar veya geçişler kullansanız da kullanmasanız da, bunun gibi bir dallanma yapısı kodunuzu geliştirme aşamasından üretime çevik ve tekrarlanabilir bir şekilde akışla aktarmanızı sağlar.

Bu yapı, müşteri geri bildirimlerine hızlı bir şekilde tepki vermenizi de sağlar. Üretime hızlı bir düzeltme yapmanız gerekiyorsa, bunu çevik bir şekilde verimli bir şekilde de yapabilirsiniz. Ana veya hazırlamadan bir dal oluşturabilir ve hazır olduğunda bunu ana ve aşağı doğru geliştirme ve özellik dallarında birleştirebilirsiniz.

Düzeltme dalı

Üretim ve geliştirme dallarının ayrılmasıyla bunun gibi bir dallanma yapısı olmadan, bir üretim sorunu sizi üretim düzeltmenizle birlikte yeni özellik kodunu tanıtma pozisyonuna sokabilir. Yeni özellik kodu tam olarak test edilmeyebilir ve üretime hazır olmayabilir ve hazır olmayan değişiklikleri yedeklemek için çok fazla çalışma yapmanız gerekebilir. Ya da değişiklikleri test etmek ve dağıtmaya hazırlamak için düzeltmenizi ertelemeniz gerekebilir.

Daha sonra Visual Studio, Azure ve Azure Repos'da bu üç desenin nasıl uygulanabileceğinizi gösteren örnekler göreceksiniz. Bunlar ayrıntılı adım adım nasıl yapılır yönergeleri yerine örneklerdir; Gerekli tüm bağlamı sağlayan ayrıntılı yönergeler için, bölümün sonundaki Kaynaklar bölümüne bakın.

Visual Studio'da kaynak denetimine betik ekleme

Betikleri Visual Studio çözüm klasörüne ekleyerek Visual Studio'daki kaynak denetimine ekleyebilirsiniz (projenizin kaynak denetiminde olduğu varsayılır). İşte bunu yapmak için bir yol.

Çözüm klasörünüzdeki betikler için bir klasör oluşturun ( .sln dosyanızın bulunduğu klasör).

Otomasyon klasörü

Betik dosyalarını klasörüne kopyalayın.

Otomasyon klasörü içeriği

Visual Studio'da projeye bir çözüm klasörü ekleyin.

Yeni Çözüm Klasörü menü seçimi

Ayrıca betik dosyalarını çözüm klasörüne ekleyin.

Varolan Öğe Ekle menü seçimi

Varolan ÖğeYi Ekle iletişim kutusu

Betik dosyaları artık projenize dahil edilir ve kaynak denetimi sürüm değişikliklerini ve buna karşılık gelen kaynak kodu değişikliklerini izliyor.

Hassas verileri Azure'da depolama

Uygulamanızı bir Azure Web Sitesinde çalıştırırsanız, kimlik bilgilerinin kaynak denetiminde depolanmasını önlemenin bir yolu da bunları Azure'da depolamaktır.

Örneğin, Düzelt uygulaması Web.config dosyasında, üretimde parolalara ve Azure depolama hesabınıza erişim sağlayan bir anahtara sahip olacak iki bağlantı dizesini depolar.

<connectionStrings>
  <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItMembership.mdf;Initial Catalog=MyFixItMembership;Integrated Security=True" providerName="System.Data.SqlClient" />
  <add name="appdb" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItTasks.mdf;Initial Catalog=aspnet-MyFixItTasks;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="true" />
  <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  <add key="StorageAccountName" value="fixitdemostorage" />
  <add key="StorageAccountAccessKey" value="[accesskeyvalue]" />
</appSettings>

Bu ayarlar için gerçek üretim değerlerini Web.config dosyanıza yerleştirirseniz veya bunları dağıtım sırasında eklemek üzere bir Web.config dönüşümü yapılandırmak üzereWeb.Release.configdosyasına yerleştirirseniz, bunlar kaynak depoda depolanır. Veritabanı bağlantı dizelerini üretim yayımlama profiline girerseniz, parola .pubxml dosyanızda olur. ( .pubxml dosyasını kaynak denetiminden dışlayabilirsiniz, ancak ardından diğer tüm dağıtım ayarlarını paylaşma avantajını kaybedersiniz.)

Azure, Web.config dosyasının appSettings ve bağlantı dizeleri bölümleri için bir alternatif sunar. Azure yönetim portalında bir web sitesinin Yapılandırma sekmesinin ilgili bölümü aşağıdadır:

portalda appSettings ve connectionStrings

Bu web sitesine bir proje dağıttığınızda ve uygulama çalıştığında, Azure'da depoladığınız değerler Web.config dosyasındaki değerleri geçersiz kılar.

Yönetim portalını veya betikleri kullanarak Azure'da bu değerleri ayarlayabilirsiniz. Her Şeyi Otomatikleştir bölümünde gördüğünüz ortam oluşturma otomasyon betiği bir Azure SQL Veritabanı oluşturur, depolama ve SQL Veritabanı bağlantı dizelerini alır ve bu gizli dizileri web sitenizin ayarlarında depolar.

# Configure app settings for storage account and New Relic
$appSettings = @{ `
    "StorageAccountName" = $storageAccountName; `
    "StorageAccountAccessKey" = $storage.AccessKey; `
    "COR_ENABLE_PROFILING" = "1"; `
    "COR_PROFILER" = "{71DA0A04-7777-4EC6-9643-7D28B46A8A41}"; `
    "COR_PROFILER_PATH" = "C:\Home\site\wwwroot\newrelic\NewRelic.Profiler.dll"; `
    "NEWRELIC_HOME" = "C:\Home\site\wwwroot\newrelic" `
}

# Configure connection strings for appdb and ASP.NET member db
$connectionStrings = ( `
    @{Name = $sqlAppDatabaseName; Type = "SQLAzure"; ConnectionString = $sql.AppDatabase.ConnectionString}, `
    @{Name = "DefaultConnection"; Type = "SQLAzure"; ConnectionString = $sql.MemberDatabase.ConnectionString}
)

Gerçek değerlerin kaynak depoda kalıcı hale getirilmemesi için betiklerin parametrelendirildiğini göreceksiniz.

Geliştirme ortamınızda yerel olarak çalıştırdığınızda, uygulama yerel Web.config dosyanızı okur ve bağlantı dizeniz web projenizin App_Data klasöründeki bir LocalDB SQL Server veritabanına işaret eder. Uygulamayı Azure'da çalıştırdığınızda ve uygulama bu değerleri Web.config dosyasından okumaya çalıştığında, geri aldığı ve kullandığı şey, Web.config dosyasındakiler değil, Web Sitesi için depolanan değerlerdir.

Visual Studio ve Azure DevOps'ta Git kullanma

Daha önce sunulan DevOps dallanma yapısını uygulamak için herhangi bir kaynak denetim ortamını kullanabilirsiniz. Dağıtılmış ekipler için en iyi şekilde bir dağıtılmış sürüm denetim sistemi (DVCS) çalışabilir; diğer takımlar için merkezi bir sistem daha iyi çalışabilir.

Git popüler bir dağıtılmış sürüm denetim sistemidir. Kaynak denetimi için Git'i kullandığınızda, deponun tüm geçmişini yerel bilgisayarınızda içeren tam bir kopyasına sahip olursunuz. Birçok kişi ağa bağlı olmadığınızda çalışmaya devam etmek daha kolay olduğundan işleme ve geri alma işlemleri gerçekleştirmeye, dal oluşturup değiştirmeye vb. devam edebilirsiniz. Ağa bağlı olsanız bile, her şey yerel olduğunda dallar oluşturmak ve dalları değiştirmek daha kolay ve daha hızlıdır. Ayrıca diğer geliştiricileri etkilemeden yerel işlemeler ve geri alma işlemleri de yapabilirsiniz. Ayrıca, işlemeleri sunucuya göndermeden önce toplu işleyebilirsiniz.

Azure Repos hem Git hem de Team Foundation Sürüm Denetimi (TFVC; merkezi kaynak denetimi) sunar. Azure DevOps ile çalışmaya buradan başlayın.

Visual Studio 2017 yerleşik, birinci sınıf Git desteği içerir. Bunun nasıl çalıştığını gösteren hızlı bir tanıtım aşağıda verilmiş.

Visual Studio'da bir proje açıkken, Çözüm Gezgini'da çözüme sağ tıklayın ve ardından Kaynak Denetimine Çözüm Ekle'yi seçin.

Kaynak Denetimine Çözüm Ekleme

Visual Studio, TFVC (merkezi sürüm denetimi) veya Git kullanmak isteyip istemediğinizi sorar.

Kaynak Denetimi Seç

Git'i seçip Tamam'a tıkladığınızda Visual Studio, çözüm klasörünüzde yeni bir yerel Git deposu oluşturur. Yeni depoda henüz dosya yok; Git işlemesi yaparak bunları depoya eklemeniz gerekir. Çözüm Gezgini'da çözüme sağ tıklayın ve ardından İşleme'ye tıklayın.

İşleme

Visual Studio, işleme için tüm proje dosyalarını otomatik olarak hazırlar ve Eklenen Değişikliklerbölmesindeki Takım Gezgini'nde listeler. (İşlemeye dahil etmek istemediğinizler varsa, bunları seçebilir, sağ tıklayabilir ve Dışla'ya tıklayabilirsiniz.)

Ekip Gezgini

Bir işleme açıklaması girin ve İşleme'ye tıklayın; Visual Studio işlemeyi yürütür ve işleme kimliğini görüntüler.

Takım Gezgini Değişiklikleri

Artık bazı kodları depodakilerden farklı olacak şekilde değiştirirseniz farkları kolayca görüntüleyebilirsiniz. Değiştirdiğiniz bir dosyaya sağ tıklayın, Değiştirilmemiş ile Karşılaştır'ı seçin ve kaydedilmemiş değişikliğinizi gösteren bir karşılaştırma görüntüsü alırsınız.

Unmodified ile karşılaştırma

Değişiklikleri gösteren fark

Yaptığınız değişiklikleri kolayca görebilir ve iade edebilirsiniz.

Dal oluşturmanız gerektiğini varsayalım; bunu Visual Studio'da da yapabilirsiniz. Takım Gezgini'ndeYeni Dal'a tıklayın.

Takım Gezgini Yeni Dal - Görüntü 1

Bir dal adı girin, Dal Oluştur'a tıklayın ve Kullanıma Alma dalı'nı seçtiyseniz Visual Studio yeni dalı otomatik olarak kullanıma alır.

Takım Gezgini Yeni Dal - Görüntü 2

Artık dosyalarda değişiklik yapabilir ve bunları bu dalda iade edebilirsiniz. Ayrıca dallar arasında kolayca geçiş yapabilirsiniz ve Visual Studio dosyaları kullanıma almış olduğunuz dalla otomatik olarak eşitler. Bu örnekte _Layout.cshtml dosyasındaki web sayfası başlığı, HotFix1 dalında "Sık Erişimli Düzeltme 1" olarak değiştirilmiştir.

Hotfix1 dalı

Ana dala geri dönerseniz, _Layout.cshtml dosyasının içeriği otomatik olarak ana daldaki içeriğine geri döner.

ana dal

Bu, hızlıca dal oluşturmanın ve dallar arasında ileri geri çevirmenin basit bir örneğidir. Bu özellik , Her Şeyi Otomatikleştirme bölümünde sunulan dal yapısı ve otomasyon betiklerini kullanarak yüksek oranda çevik bir iş akışı sağlar. Örneğin, Geliştirme dalında çalışıyor, main'ın dışında bir sık erişimli düzeltme dalı oluşturabilir, yeni dala geçebilir, değişikliklerinizi orada yapabilir ve işleyebilir ve ardından Geliştirme dalı'na geri dönüp yaptığınız işe devam edebilirsiniz.

Burada gördüğünüz, Visual Studio'da yerel bir Git deposuyla nasıl çalıştığınızdır. Ekip ortamında genellikle değişiklikleri ortak bir depoya da gönderebilirsiniz. Visual Studio araçları, uzak bir Git deposuna işaret etmenizi de sağlar. bu amaçla GitHub.com kullanabilir veya git ve Azure Repos iş öğesi ve hata izleme gibi diğer tüm Azure DevOps özellikleriyle tümleştirilmiş olarak kullanabilirsiniz.

Elbette çevik dallanma stratejisini uygulayabilmenizin tek yolu bu değildir. Merkezi bir kaynak denetimi deposu kullanarak aynı çevik iş akışını etkinleştirebilirsiniz.

Özet

Kaynak denetim sisteminizin başarısını, ne kadar hızlı bir değişiklik yapabileceğinize göre ölçün ve güvenli ve öngörülebilir bir şekilde canlı hale getirin. Bir veya iki gün el ile test yapmak zorunda olduğunuz için değişiklik yapmaya korkuyorsanız, bu değişikliği dakikalar içinde veya en kötü ihtimalle bir saatten uzun sürmeyecek şekilde işlem açısından veya test açısından yapmanız gerekenleri kendinize sorabilirsiniz. Bunu yapmak için bir strateji, bir sonraki bölümde ele alacağımız sürekli tümleştirme ve sürekli teslimi uygulamaktır.

Kaynaklar

Dallanma stratejileri hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:

Kaynak denetimi depolarında tutulmaması gereken hassas bilgileri işleme hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:

Hassas bilgileri kaynak denetiminin dışında tutmaya yönelik diğer yöntemler hakkında bilgi için bkz. ASP.NET MVC: Özel Ayarları Kaynak Denetiminin Dışında Tut.

ÖncekiSonraki