Azure üzerinde "Continuous Delivery" tanımları ve anahtar noktalar

Visual Studio ile geliştirilen projeyi Azure üzerinde yayına almak için yeni bir "Publish Profile" oluşturulabilir ve sonradan istenildiği anda geliştirmeler bu tanım üzerinden doğrudan yayına alınabilir:
https://docs.microsoft.com/en-us/aspnet/core/tutorials/publish-to-azure-webapp-using-vs

Projeyi yayına almak için diğer alternatif yöntemler:
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-deploy

Genel olarak .Net Core ile geliştirilen projelerde hem Azure üzerinden hem VSTS üzerinden standart şablonlar ile CI/CD tanımlarını yapmak problemli. (Temmuz 2017 itibariyle).
Dolasıyla hem entegrasyonu çalışır hale getirmek hemde ihtiyaçları karşılaması amacıyla oluşturulan şablonları düzenlemek gerekiyor.

Azure CLI

Azure portal'e giriş yapmadan https://shell.azure.com ya da Azure CLI tools kullararak alttaki komutlarda slot swap işlemi gerçekleştirilebilir

azure site -h > To list the commands available for Azure App Service in the Azure CLI

azure site list

azure site list lingo-member > will list lingo-member and lingo-member-staging

azure site swap lingo-member > Swap slot "staging" from site "lingo-member" with slot "production" ? [y/n]

---cli swap
az webapp deployment slot swap -g lingo-live -n lingo-member -s staging
---log download
az webapp log download -n lingo-parse -g lingo-live

Geliştirme ortamından yayına alma süreci

Kalitenin korunması başta olmak üzere diğer nedenlerle birlikte önerilen yöntem otomasyon sürecinin oluşturulması.
Geliştirme ortamından yayına alma sürecinde yaşanabilecek olumsuzluklar:

Problemler

Geliştirme ortamından Azure ortamında aktarım yaparken karşılaşılabilecek hatalardan biri;


C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\PublishTargets\Microsoft.NET.Sdk.Publish.MSDeploy.targets(134,5):
Warning : Retrying the sync because a socket error (10054) occurred.
Retrying operation 'Serialization' on object sitemanifest (sourcePath). Attempt 1 of 10.

Bu hatanın nedeni yüksek ihtimal bağlantı probleminden kaynaklanmakta.
Download hızından bağımsız olarak upload hızı en yüksek 700Kb seviyesinde ve bu çoğu zaman daha düşük. Dolayısıyla küçük bir projeyi bile yayına almak bir kaç dakika sürüyor ve bu sırada başka bir dosya gönderimi yapılmamalı.

Kesinti

Diğer oluşabilecek bir problem aktif kullanımda olan bir sitenin/web servis güncellemesine uygulama servisinin izin vermemesi. Dolayısıyla servisi yeniden başlatma gereksinimi ve bu da yayında kesintiye sebep olmakta.

Test

Ve tabiki en önemli neden aktif kullanımda olan bir ürünün test edilmeden yayına çıkılmaması gerektiği. Test için geliştirilmişse test projesinin otomasyon sürecinde otomatik çalışması ve canlı benzeri (staging) ortamda projeyi yayına alınıp yapılan geliştirmelerin manuel kontrolun yapılması.

Otomasyon sürecinin oluşturulması

Genel olarak Continuous Delivery tanımı için:
https://www.visualstudio.com/en-us/docs/build/aspnet/core/quick-to-azure

Özet olarak otomasyon sürecinin oluşturulması için bir Azure hesabı bir de Visual Studio Team Services hesabı olmalı: https://www.visualstudio.com/team-services/

Visual Studio üzerinden yapılan geliştirmeler Git veya TFS entegrasyonuyla "source control" ortamına aktarılmalı ve istenen tanıma göre, örneğin her check-in yapıldığında otomasyon süreci tetiklenmeli.

Dolayısıyla en temel süreç : Geliştirme > Check-in > Build > Running Tests > Deploy
şeklinde özetlenebilir.
Test kodlarının çalıştırılması var olmalarına bağlı ve dolayısıyla kolayca atlanabilir. Sonraki büyük problemde yaşanacak pişmanlığa kadar...

Deploy için Azure üzerinde sağlanan faydalı özelliklerden biri (Premium App service için) Deployment Slot tanımlayabilme.

Bu şekilde yapılan geliştirmeler direk canlıya almak yerine örneğin staging/yayın öncesi son test ortamına alması sağlanabilir. Dolayısıyla geliştirmeyi canlı ile aynı ortamda test etme imkanı doğar. Malesef bu test canlı kullanım ortamı/yoğunluğu değişkenlerinden bağımsızdır.

Slot tanımının diğer önemli faydası kesinti süresinin düşürülmesi hatta ihmal edilmesini sağlar.

Staging ortam tanımlarında Swap işlemi ile Staging ve Production ortamı yer değiştirir.
Dolayısıyla problem tespitinde önceki versiyona geri dönüş de yapılabilir.

Stage ortamı tanımları ve yayına alma
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing

Release Definition editor'un detaylı anlatımı:
https://blogs.msdn.microsoft.com/visualstudioalmrangers/2017/07/05/a-really-cool-feature-we-noticed-on-vsts-new-release-definition-editor/

Azure CI/CD sürecinin oluşturulmasında dikkat edilecekler

-Web App/Api de Continues Delivery adımında gerekli tanımları yaparken Repository seçtikten sonra
-App type da .Net Core (.Net framework ile birlikte) düzgün çalışmıyor (Temmuz 2017 itibariyle).
VSTS portal de bu configurasyon seçeneği var.

-CI tanımları Staging slot üzerinden değil Production üzerinden yapılır.

-Deployment için önce staging slot a deploy et seçeneği seçilir. Staging slot oluşturulmuşsa o seçilirse yoksa yeni oluşturulabilir.

-Tanım sonrası düzenlenecek nokta.
-Her checkinde auto deploy oluyor ve Staging'den Production'a auto swap oluyor.
Maliyet den dolayı her checking de auto build/deploy iptal.
Auto swap öncesinde test için iptal edilmeli. Dolayısıyla prod a deploy manuel.

-NodeJs projesinde repository config de solution seçiliyor. Dolayısıyla Deployment config de root directory olarak proje dizini verilmeli ki onun altındakileri deploy etsin.

-En son canlıya almak için Staging slot a gidip Swap denir (source: staging > target: production)

https://github.com/projectkudu/kudu/issues
https://www.visualstudio.com/en-us/docs/build/get-started/aspnet-4-ci-cd-azure-automatic

https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing

Build / Release tanımlarında dikkat edilecekler

Build tanımı hem Azure App Service üzerinden hem de Team Services üzerinden yapılabilir.

Azure üzerinden:

VS Team system: Continues Integration Hatalar
Continues Integration da build hatası
##[error]Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
Build adımında hata:
Error CS0400: The type or namespace name 'System' could not be found in the global namespace
(are you missing an assembly reference?)

Çözüm ek adım:
http://www.codewrecks.com/blog/index.php/2017/05/24/build-net-standard-multitargeted-solution-in-vsts/
Release
https://www.thaianhduc.com/2017/06/asp-net-core-full-lifecycle-from-laptop-to-cloud/


NodeJs projesinde Build Definition tüm dosyaları zipliyor. Dolayısıyla ilgisiz (.njsproj) da canlı ortama aktarılmış oluyor.

Azure App Service ve Deployment Slot tanımında dikkat edilecekler

Slot "ortamı": Proje dosyalarının konulduğu ortam. Genelde iki slot olur. Production ve Staging.
Swap "işlemi": Slotların yer değiştirilmesi işlemi.

Deployment Slot+Swap problemi

Site için WebJob tanımlanmışsa, örneğin:
Eğer Letsencrypt gibi ücretsiz servis ile SSL kurulumu yaptıysanız:
Letsencrtp için yapılan tanımlarda iki dizin oluşuyor:
.well-known (1 KB) ve App_Data\jobs\continuous\letsencrypt64(letsencrypt.siteextension.job) (20 MB)
VS üzerinden yayına alırken ayarlardaki "yerelde olmayan dosyaları sunucuda sil" tanımı seçili olmamalı.
Yoksa üstteki dizinleri siliyor.

Diğer nokta Slot swap da. Staging'e deploy edip swap deyince production ve staging yer değiştiriyor.
Dolayısıyla staging'de olmayan üst dizinler prod dan kayboluyor. staging'e de bir defa bu dizinler kopyalanmalı.
Kudu ekranından Debug Console/Cmd ile dizin listesinde wwwwroot altına local den sürükle bırakla kopyalanabilir.
https://x-site.scm.azurewebsites.net/DebugConsole
Dosya işlemleri için: http://www.jamessturtevant.com/posts/How-to-add-edit-and-remove-files-in-your-azure-webapp-using-the-kudu-service-dashboard/

App_Data/job dizini altında eğer tanımları yapılmışsa Application Insights için tanım ve kütüphanelerde bulunmakta.

https://github.com/projectkudu/kudu/wiki/WebJobs
Web job ayarları

Staging slot Application Settings de "WEBJOBS_STOPPED=1" tanımı yapılmalı.

Staging domaini için IP kısıtı tanımlama
http://ruslany.net/2014/04/azure-web-sites-block-web-access-to-non-production-deployment-slots/

Oluşturulan Nuget paketlerinin servis üzerinden yayına alınması

Create a Free Private NuGet Server with Continuous Deployment using VSTS
https://www.devtrends.co.uk/blog/create-a-free-private-nuget-server-with-continuous-deployment-using-vsts