#VSTS is now @AzureDevOps: 5 services you can use together or independently, including Azure Pipelines for CI/CD – free for open source and available in the GitHub CI marketplace. Learn more: https://t.co/fApjw1FThY pic.twitter.com/GUato050Zg
— Azure DevOps (@AzureDevOps) September 10, 2018
Açık kaynak projelerin kod deposu olarak hayatımıza giren GitHub, yazılım teknolojilerinin olmazsa olmaz bir parçası oldu artık. Benzer şekilde Visual Studio Team Services(VSTS)’de uçtan uça bir kod geliştirme alt yapısı sunduğu ve bulut servisi olmasından dolayı da oldukça tercih edilen bir platform. Özellikle Team Foundation Server(TFS) ile bir şekilde haşır neşir olanların bir sonraki basamağı…Neyse şimdi VSTS’in ayrıntılarına girmeyelim, çıkamayız.
Bu yazıda basit bir senaryo ile GitHub’da kodlarını barındırdığımız bir projeyi, VSTS üzerindeki bir “build-relase” adımları ile Azure’da ki bir App Service’e dağıtımını yapacağız. Bir nevi Continuous Deployment(CD) sürecini basitçe bir VSTS üzerinde oluşturacağımız bir pipeline ile gerçekleştireceğiz. Anahtar kelimeleri de paylaştığıma göre başlayabilirim 🙂
Bu arada bu bahsetmiş olduğum senaryoyu bu yazıyı yazdığımdan daha kısa sürede gerçekleştirdim. Artık kullanılan sistem ve platformların etkin ve kolay olması bir çok ihtiyacta kurtarıcı oluyor. DevOps yaklaşımı anlamak, farklı sistemler ile bir uygulamayı nasıl belli platformlara dağıtabiliriz ön ayak olması için umarım faydalı olur.
Build…
Bu senaryoda GitHub’daki Notify.Me projemdeki kod repository’sini kullanacağım.(Belli bir PoC çalışması için yapılan, ASP.NET Core ile SignalR projesi) Zaten bir kod kaynağımız olduğu için ilk iş olarak VSTS’de Build adımını gerçekleştirmek. VSTS’deki menüdeki “Build and release” başlığından “Builds” menüsüne giriyoruz.
Haaaa; bu arada, bu yazıdaki ekran görüntüleri sizin VSTS hesabınızdan farklı ise, sağ üst köşedeki kullanıcınız üzerinden “Preview features”dan yeni görsel özellikleri açabilirsiniz.
“Builds” kısmında kod deposu olarak seçebileceğimiz seçenekleri göreceksiniz. Burada oldukça geniş bir kümeye sahibiz; Team Foundation Version Control(TFVC), GitHub, Bitbucket, Subversion. Yok yok… 🙂

Biz GitHub’ı seçiyoruz tabi ki. GitHub’ı seçince, GitHub hesabımız ile VSTS’i ilişkilendirmek için Login olmamız ve sonrasında gerekli izinleri vermemiz gerekiyor. Ekranların yönlendirmesi ile kolayca bunları yaptıktan sonra, GitHub’daki hangi projemizi derlemek istiyorsak onu seçiyoruz. Projemizde farklı branch’ler varsa, derleme işlemi için onu da belirtiyoruz.
Daha sonra gerek duyduğumuz derleme şablonunu seçiyoruz. Bu şablonlar derleme aşaması için genel kullanımlarda gerek duyulan adımların oluşturulduğu hazır şablonlar. Bu şablonlardan birini seçmek yerine direkt olarak boş bir şablon oluşturup, adımları kendiniz ekleyebilirsiniz.


Notify.Me bir ASP.NET Core 2.x uygulaması olduğu için, burda ASP.NET Core şablonunu seçiyorum. Daha sonra seçtiğim derleme şablonuna göre belli adımlar karşımıza çıkıyor. Bu ekranda, bu adımların ayarlarını düzenlemek yetiyor. Hangi komutların çalışacağı, hangi projelerin build olacağını gibi ayarlar…

Açıkcası burada ekranlar oldukça kolay ve güzel oluşturulmuş diye düşünüyorum. Takıldığınız bir adım olursa onun çeşitli label’ları ile adım hakkında bilgi ve hatta ayrıntılı ek bilginin linki oluyor.
Bu senaryoda seçtiğim GitHub repository’sinde hangi projeyi build edeceğimi ayarlıyorum, ayrıca Restore ve Test görevlerini de disable ediyorum. İstediğimiz adımları enable/disable edip “Build Pipeline”nında çeşitli durumları deneyebiliriz. Komple de kaldırabiliriz tabi ki. Hatta isterseniz farklı görevler(task) ekleyerek build aksiyonlarını zenginleştirebilirsiniz. VSTS’in mevcut taskları dışında, Visual Studio Marketplace’den de farklı task’ları kullanabilirsiniz. Tek tek bunlardan bahsetmeyeceğim, -ki edemem zaten,zamanımız yetmez 🙂 Ama oldukça zengin bir görev kümesi mevcut.

“Build” işleminin nasıl tetikleneceğini de derleme ayarlarındaki “Triggers” altından ayarlamak mümkün. GitHub’daki projeye her bir commit‘de build adımını tetikleyebiliyorum bu şekilde. Sadece belli branch’lere yapılan commit’leri ya da GitHub’daki “Pull Request”lere göre de tetiklemek mümkün.



“Legacy” dediğimiz uygulamalar, sistemler öyle önemli bir değer yaratmışlar ki hala günümüze denk yaşayabilmişlerdir demek ki. 10, 15, 20 yıldır ayakta olan uygulamaları düşünün; ilk kullanıldıkları dönemlerden beri insanlara ve belli iş modellerine o kadar çok değer katıyorlar ki, hala o değeri koruma mücadelesinde içindeler… Biraz daha toparlamak gerekirse “Legacy” diye adlandırdığımız uygulamalar, ne kadar çok negatif bileşenle günümüze gelse de sahip oldukları “değer” çok önemlidir… Ve bu değer uygulamaların en güçlü özelliğidir.
Bahsetmiş olduğum bu dokümante edilmeyen SP’ler, bir çoğumuzun sistem nesneleri diye bildiği sys. şeması altında. sp_MS% ile başlayan bu SP’ler isimlerinden kısmen yaptıklarını anlatır durumda. Tüm SQL Server seviyesinde gerçekleştirmek istediğiniz bir çok operasyonu bu SP’ler sayesinde yapabiliyorsunuz. Mesela SQL Server’daki tüm veri tabanlarında bazı değişiklikler yapmak, bir veri tabanındaki tüm tablodaki INDEX’leri tekrardan oluşturmak, veri tabanındaki tüm tabloların isimlerini değiştirmek ya da spesifik kolon eklemek gibi gibi işlemleri bu SP’ler sayesinde yapabiliyoruz.
Çok basit ve yalın olması için, “Machine Learning” ’in bilgisayar sistemlerinin bir öğrenme süreci olduğunu söyleyebilirim. Verilerin, bilgiye dönüşmesi için bilgisayar sistemlerinin gücünün kullanıldığı teknik bir süreç… Açıkcası ne olduğu sorusundan çok, nasıl olduğu sorusunun, “Machine Learning” ‘in anlaşılması ve öğrenilmesi için daha önemli olduğunu düşünüyorum. “Nasıl?” sorusunun cevabı tabi ki çok geniş ve ayrıntılı. Ben sadece giriş tadında olması için bazı fikirlerimi paylaşmaya çalışacağım.
Verilerdeki belli kalıpların bulunması, “Machine Learning” sürecinin temeli. Verilerdeki kalıpların bulunması ve bunların üzerinde çeşitli algoritmalar çalıştırılması ile sistemler öğrenebilir hale gelmeye başlıyor. Bu süreç aslına bakarsanız iteratif yani kendini tekrarlayan bir süreç. Sistemlerin öğrenebildiğinin doğrulanması ve geçerli olduğunun kabul edilmesi gerekiyor. Bu sayede öğrenme hızı ve şeklide gelişiyor doğal olarak. Bu doğrulamayı ve kabulu de, aslında biz ya da bizim oluşturduğumuz sistematik süreçler yapıyor. Bilgisayar sistemlerinin öğrenme yaklaşımı çeşitli “tahmin etme” yaklaşımları ile somutlaşıyor. Bizim için en önemli çıktı bu şekilde oluşuyor aslında. Bu tahminlere göre, belli durumlarda da tanımlı aksiyonlar gerçekleştiriliyor. Bu sayede bir çok kolaylık insanoğlu için sağlanıyor. (Yapay zekanın temeli de bu aslında.)
Biraz daha anlaşılır olması için hepimizin geçtiği bir süreçten bir örnek verebilirim. Açıkcası okuma-yazma öğrenme süreci bütün bu “Machine Learning” konseptinin anlaşılması için güzel bir giriş noktası bence. Hepimiz okuma yazmayı; hatırlarsınız belli çizgiler çizerek harfleri öğrenerek başladık. Daha sonra harflerin bir araya geldiği kalıpları bulup, bu kalıpların tekrarlanmasını çıkartıp kelimeleri tanımlayabilir hale gelmiştik. Kelimelerin anlamlarını da çıkartıp, benzer kelimelerin anlamlarının ne olabileceğini tahmin edip, yeni kelimelerin anlamını çıkarmıştık. Bu sürecin sürekli tekrarlanması ile kelime dağarcığımız gelişmiş ve okumayı da böyle böyle çözmüştük. Çok geçmiş zaman kullandım ama temel olarak öğrenme süreci hala böyle aslında. 🙂