.NET Core Build – Continuous Integration (CI) ve Versiyon Yönetimi

​Yazılım geliştirme süreçlerinde bizlere hız katan bir diğer unsur, proje çıktılarının, ürettiğimiz paketlerin hızlı bir şekilde kullanıma ve dağıtıma hazır hale getirilmesidir. Özellikle dağıtık mimarilerde, kapsamlı yığınlar içeren kütüphanelerin sürekli proje içerisinde kalması, derlenmesi fazladan yönetim ve zaman kaybına sebep olabilmektedir. Tam bu noktada; Continuous Integration (CI) kavramı ve gereklerini ifa eden yazılımlar seçenekler arasında yerini almaktadır.
Team Foundation Server, Jenkins, Travis CI isimli araç ve yazılımlar ister Command Line arayüzü ile ister web görselleri ile bizlere CI sürecinde ihtiyaç duyabileceğimiz API, SDKs araçlarını sunarlar.
Bugün burada örneklemeye çalışağım yığın .NET Core ve Team Foundation Server’ ​​ı kapsayacaktır.
Team Foundation Server 2015 sürümünden itibaren geliştiricilere farklı seçenekler sunulmaktadır. Özellikle Cross-Platform Build ve CI başta olmak üzere, OSX, Linux ve Windows ortamlarına ait araç ve ortamlar, farklı programlama dillerinin derlenmesi, Command-Line, PowerShellaraçları ve daha bir çok yeni yetenek TFS bünyesine kazandırılmıştır.

​​

Bir .NET Core Web projesinin belirli bir SDK ve Runtime a göre derlenip, dağıtıma uygun hale getirilmesi amacıyla şu adımları takip edebiliriz. TFS ve Agent Ayarları
​Bir .NET Core projesini derlerken DotNet CLI, .NET Core SDK ve .NET Core Runtime üçlüsüne ihtyaç duyarız. NET Core’ un Cross-Platformdesteği editor ve IDE bağımlılıklarınıda ortadan kaldırmayı hedeflemektedir. Böylelikle projeniz ile ilgili; derleme (build), paketleme (pack) ve dağıtim (deploy – publish) süreçlerini Command Line (komut satırı) ile gerçekleştirebilirsiniz.
Örnek bir derleme sürecini komut satırından şu şekilde başlatabiliriz:dotnet build –configuration Release ​​​Eğer bir Visual Studio 2017 sahibi iseniz dotnet cli aracı varsayılan olarak MSBuild destekli gelmektedir. .NET Core için de .csproj formatlı proje yapısına geçilmiş olması MSBuild’ in .NET ve .NET Core için benzersiz bir derleyici olarak sahne almasını sağlamıştır. Böylelikle yeni proje yapısında derlemeyi ayrıca şu şekilde sağlayabiliriz:dotnet msbuild /p:Configuration=Release ​​​Böylelikle .csproj uzantılı .NET Core kütüphanelerini veya çalıştırılabilir projeleri MSBuild aracını kullanarak derlemiş oluruz.
Team Foundation 2015 sunucusunun yerel ağınızda konumlandırıldığını varsayıyorum. Geliştirme ortamında kullandığınız dotnet cli sürümünün TFS sunucusunda kurulu olması gerekmektedir. .NET Core için TFS’ in önceki sürümlerinde kullanılan Release Management aracı veya Visual Studio kurulumuna ihtiyaç duymayacağız. Buna göre;Geliştirme ortamımızda kullandığımız dotnet versiyonunu (SDK, Runtime) TFS sunucusuna kurmamız gerekmektedir.Web Deploy 3.6 aracının kurulu olduğundan ve TFS sunucunuzda (Agent’in çalışacağı – TFS ile aynı sunucuda konumlandırabiliriz) komut satırından msdeploy.exe komutuyla çalıştığından emin olunuz.set PATH=%PATH%;C:Program FilesIISMicrosoft Web Deploy V3
3. ​​Tüm operasyonları gerçekleyecek olan Agent kurulumu için TFS sunucunuzdan Agent’ i indirmeniz gerekmektedir.​​
​
​

agent.zip i istediğiniz bir klasöre çıkartıp ConfigureAgent.cmd dosyasını komut satırından Administrator olarak çalıştırmanız gerekmektedir. Sırasıyla aşağıdaki adımları kendi değişkenleriniz ile belirlediğinizde;​

tek yapmanız gereken TFS sunucunuzda (Agent’ ın çalışacağı sunucu) tanımlı ve gerekli izinlere (TFS Yöneticisi vb.) sahip bir kullanıcı ile açılmış komut satırı oturumunda (terminal session) RunAgent.cmd dosyasını çalıştırmanızdır.
​​Build Adımları
Yukarıda belirtilen adımları tamamladığımızda Agent’ı TFS sunucumuzda Agent Queues sekmesinde Idle durumda görüyor olmamız gerekmektedir. Bundan sonrası bir Build Definition (Derleme Tanımı) ile devam etmektedir. (Project->Build->Create new build definition)

1. Adım: Temizlik 😉
Obj ve Bin klasörleri sebebiyle oluşabilecek hataları önlemek amacıyla derleme işleminin yapıldığı kök dizinde yeni bir sayfa açalım. (Add Build Step -> Utility -> Delete Files) Bunun için:​

Burada hangi .csproj veya .sln dosyasını kullanıyorsak Source Folder alanında belirtmemiz gerekmektedir. 2. Adım: dotnet msbuild (Build)
Kritik bir adım, parametreler ve gereksinimler kusursuz olmalı. (Add Build Step -> Utility -> Command Line)

Tool adını dotnet olarak belirleyip argümanları sırasıyla:​

msbuild /t:Restore,Rebuild,Publish /p:OutputPath=bin/$(Build.DefinitionName) /p:Configuration=Release /p:Platform=x64
​​yukarıdaki şekilde belirtiyoruz. Böylelikle projemiz ilk olarak bağımlılıkları Nuget’tan varsa yerel ağdan veya projeden toparlıyor, derleniyor ve belirtiğimiz dizine Release modda ve x64 platform destekli dağıtım için gerekli dosyaları oluşturuyor. Burada TFS ön tanımlı değişkenlerden birinin kullanımını örnekliyoruz. $(Build.DefinitionName) 3. Adim Temp
Geçici dosyalarınızı tutmayı planladığınız dizini gerekliyse 1. adımdaki yöntem ile temizleyebilirsiniz. 4. Adım: MSDeploy.exe
Oluşturduğumuz dağıtım paketini farklı sunucularda çalışan IIS (Internet Information Services – Web Server) sunucularına basit bir komutla güncelleme veya yükleme yapabilmek için:

Tool adını msdeploy olarak belirleyip argümanları sırasıyla:
-verb:sync -source:contentPath=%cd%bin$(Build.DefinitionName)publish -dest:package=$(buildFullPath)$(Build.DefinitionName).zip -declareParam:name=”IIS WebApplication Name”,defaultValue=”$(Build.DefinitionName)”
şeklinde belirtiyoruz. Böylelike msdeploy uyumlu .zip formatında uygulama dağıtım paketi elde etmiş oluyoruz. 5. Adım: Dosya Kopyalama
Paketin sunucular tarafından okunabilen bir ağ dizinine (UNC Path) kopyalanması amacıyla

yukarıdaki adımı uyguluyoruz. $(buildFullPath) isimli değişken sizin belirlediğiniz sabit bir dizin olmalıdır. Target Folder alanı ise diğer sunucularında erişebileceği bir dizini işaret etmelidir. Örneğin \10.1.1.11releases gibi. Bu durumda değişken değeri \10.1.1.11releasesWebClient.zip şeklinde olacaktır. 6. Adım: TFS Release Paketinin oluşturulması
Bu adımda derleme ve paket işlemi tamamlanmış olan bir dosyanın TFS ortamında daha sonra bu paketi kullanacak (ilişkilendirilecek) olan Release için hazır edilebilmesi amacıyla tüm öğeleri uygun dizine yerleştiriyoruz. (Build artifacts)

Böylelikle derleme ve dağıtım için gerekli 6 adımı tamamlayıp uygulama paketini elde etmiş oluyoruz. Release
Uygulama paketinin hangi sunuculara ve ne tip ön gereksinimler ile dağıtılacağını bu süreçte belirleyebiliriz. Bunun için ben ilgili sunucularda WinRM özelliğini tercih ediyorum. WinRM aracı sunucularda bağlantıda belirtilen PowerShell dosyası ile özelleştirildiğinde, canlı ortama güncel versiyonun veya paketin aktarım işlemine şu seçenekler ile başlayabiliriz.WinRM – IIS Web App ManagementPowerShell on Target Machines​

Yukarıda belirtilen değişkenler sizin ortamınıza göre belirlenmelidir. Örnek olarak:

Hedef sunucuda WinRM aracılığıyla çalıştırılacak olan (C:scriptsDeployWebsite.ps1) DeployWebsite Github Gist dosyasının hedef sunucu için belirttiğiniz dizinde olduğundan emin olunuz. Aşağıda belirtilen alanlar TFS Release -> Configuration bölümünden tanımladıktan sonra Agent tarafından tetiklenebilecektir.

Belirtilen PowerShell dosyası msdeploy.exe yi kullanarak belirlediğimiz parametreler ve aşağıdaki komut ile

-packagePath:$(releasePath)$(relatedBuildName)$(relatedBuildName).zip -siteName:$(relatedBuildName) -siteFullPath:$(physicalPath) -environmentName:$(Release.EnvironmentName)

hedef sunucu(lar)da çalıştırılacak ve işlem tamamlandığında uygulamanızın yeni sürümünü canlı ortama almış olacaksınız.
Bir defaya mahsus yapacağınız bu işlemler neticesinde bundan sonra istediğiniz zaman canlı ortama çok hızlı bir şekilde versiyon çıkabilecek veya paketlerinizi güncelleyebileceksiniz. Müthiş değil mi? Bu şekilde 1,5 dakikada 11 sunucuya versiyon çıkalabilmektedir. (Environment – Prod Applications).
​​BONUS: TFS CLI
Bu komut satırı aracını kullanarak birçok işlemi hızlıca gerçekleştirebiliyoruz. TFS REST API hizmetlerini kullanan bu araç ile özel çözümler geliştirebilirsiniz.
Faydalı olması dileğiyle…

​