Xbox Game Pass for PC One Month Key Giveaway

Discover your next favorite game!Unlimited access to over 100 high-quality PC games on Windows 10. Download and play new games on day one like Gears 5—plus recent blockbusters like Age of Empires II...
BeğenFavori PaylaşYorum yap
Önceki yorumları gör 9 / 10

macOS Hackintosh AMD Ryzen Bilgisayar Ryzentosh Üzerine Nasıl Kurulur & Yapılandırılır

Merhaba ben Kemal ALKIN 🙂

"Herkes için macOS (macOS for everyone) sloganıyla yola çıktığım; AMD ve Intel tabanlı sistemlere macOS kurulumu sağlamak için geliştirdiğim kealOS imajlarının yapımcısıyım. KemalALKIN nickim ile 2008/9 yılından itibaren Hackintosh kurulumlarına başladım. 2011 yılından bu yana çeşitli online platformlar ve bireysel iletişim aracılığıyla kurulum desteği sağlamaktayım."

Bugün sizlere ekran görüntüleriyle bir anlatım hazırladım. Videolu anlatımlarımı ise yakın zamanda hazırlayacağım ve sizlere sunacağım.

macOS Hackintosh AMD Ryzen Bilgisayar Ryzentosh Üzerine Nasıl Kurulur & Yapılandırılır

Kullandığım (geliştirdiğim) kurulum imajı:
https://www.macosforeveryone.com/kealos-mojave-10-14-5-amd-intel/

Ekran alıntıları sayfaya sığmadığı için blogum üzerinden bakabilrsiniz:
https://www.macosforeveryone.com/how-to-install-configure-macos-hackintosh-amd-ryzen-pc-ryzentosh/

BeğenFavori PaylaşYorum yap

Video – Hackintosh PC: i9 9900K | Z390-A | RX VEGA 64 | macOS Mojave – kealOS

https://youtu.be/2a4vx8vW9dc

Kemal ALKIN tarafından Tuncay Tiryaki için toplanmıştır ve macOS kurulmuştur.

– İNTEL İ9 9900k İşlemci
– ASUS Rx Vega 64 8 GB (OC) Hmb2 Ekran Kartı
– ASUS Z390 Prime – (A) Anakart
– GSKILL 16 GB (2x8GB) Trident Z RGB DDDR 4 3200mhz CL16 RAM
– SAMSUNG 970 EVO 500 GB SSD
– COOLER MASTER Masterliquid ML240R Sıvı Soğutucu
– CORSAİR HX 1200W +80 PLATİNUM Power Supply
– WD BLACK 4 TB 256MB Cache Harddisk (3,5)
– 4 ADET Kumanda Kontrollü RGB 120mm FAN
– 2 METRE Kumanda Kontrollü RGB LED ŞERİT
– WTXUP Broadcom 1300Mbps Wifi + 4.2 Bluetooth (Hackintos Uyumlu)
– KASA COUGAR Conquer Gaming

BeğenFavori PaylaşYorum yap
Önceki yorumları gör 7 / 9

Format atmaya son. Eğer sende 15 dakikada formatla uğraşmadan sistemi yeni hale getir rahat et. Acronis candır. Gerisi heyecan.
40 GB lık veriyi 15 dakika sürmeden eski haline döndürebiliyorum. Büyük nimet. Nimetle şaka olmaz bu arada. 😂😂
Kullan rahatını çıkar.
(Not: reklam almadım sadece acayip kolaylık sağladığı için sizinle paylaşmak istedim.)

BeğenFavori PaylaşYorum yap
Önceki yorumları gör 10 / 23

AZURE DEVOPS ÜZERİNDEN ON-PREMİSES IIS SERVER ÜZERİNE WEB SİTESİ YAYINLAMA

Merhaba,

Bu yazımda Azure DevOps üzerinden yapmış olduğumuz Web Site’lerimizi On-Premises üzerinde bulunan IIS sunucumuzda yayınlamayı anlatacağım.Yayınlayacağınız Web Site’sinin gerekli olan eklenti paketlerinin ve IIS Server’ın çalışması için gerekli olan tüm özelliklerin Server Manager üzerinden yüklendiğini kontrol etmelisiniz. Aksi takdir de yayınlamış olduğunuz Web sitesi çalışmayacaktır. IIS Server’ın hazırlanması konusunda geliştirici takım arkadaşlarınızdan veya şirketinizde bulunan orta katman sistem yöneticilerinden destek alabilirsiniz.

Burada yapmak istediğimiz kısım Web Sitemizi Azure üzerinde App Service Plan oluşturmadan ve ücret ödemeden On-Prem yapımızdaki IIS Sunucu’yu kullanarak maliyetleri azaltmaktır veya direk On-Prem yapımızda Web sitemizi yayınlamaktır.

 

Adımlara başlayabiliriz,

 

1.Azure DevOps üzerine giriş yapıyoruz ve yeni bir proje oluşturuyoruz. Proje’nin erişilebilirlik durumunu ve versiyonlama türünü seçerek projemizi oluşturuyoruz.

 

 

 

 

2.Projemiz başarı ile oluştu. Şimdi bilgisayarımızda üzerinde yeni bir Web Projesi oluşturma ile devam edeceğiz.

 

 

 

3.Web projesi oluşturarak devam ediyoruz.

 

 

 

 

 

 

4.Oluşturduğumuz uygulamamıza bir adet kaynak kontrolü ekliyoruz.

 

 

 

5.Azure DevOps üzerinde projemizi seçiyor ve bir klasör oluşturuyoruz.Uygulamamız seçtiğimiz projenin içindeki, oluşturduğumuz klasörün içinde tutulacaktır.

 

 

 

6.Bu işlemlerden sonra Team Explorer’a gelerek uygulama dosyalarının Azure DevOps üzerine gönderilmesini sağlayacağız.Team Explorer içinde bulunan Pending Changes kısmına geliyoruz.

 

 

 

7.Dosyaların Azure DevOps üzerine eklenmesi için check In atıyoruz.

 

 

 

 

8.Uygulamamız Azure DevOps içinde bulunan Repos kısmına gelmiş.Şimdi On-Prem IIS sunucumuzu eklemek için Azure DevOps ana ekranına döneceğiz.

 

 

 

 

9.Organization settings kısmına geliyoruz.

 

 

 

10.Açılan menü de Deployment pools kısmına gelerek sunucumuzu eklemeye başlıyoruz.

 

 

 

11.Yeni bir deployment pool oluşturuyoruz.

 

 

 

12.Oluşturacağımız Deployment Pool’a bir isim veriyoruz ve hangi proje için kullanacaksak o projeyi seçiyoruz.

 

 

 

13.Ekranda bulunan PowerShell Script’ini On-Prem yapımızda kullanacağımız IIS Sunucu’da PowerShell üzerinde çalıştırıyoruz.PowerShell’i admin modun da çalıştırmayı unutmayınız.

 

14.Script’i çalıştırdıktan sonra bizden bir doğrulama istediğini görüyoruz.Bu doğrulama işlemini Token ile yapacağız.Bu token script ile yüklenmiş agent’ın Azure DevOps üzerinde oluşturduğumuz Deployment Pool’una bağlanmasını sağlayacaktır.

 

 

 

 

15.Bu ekran da bizden bir token id istiyor.Bu token ID’yi alabilmek için aşağıdaki adımları uygulayacağız.

 

 

 

 

16.Giriş menüsü içinden Security kısmına geliyoruz.

 

 

 

17.New Token diyerek oluşturma işlemine başlıyoruz.

 

 

 

18.Oluşturduğumuz Token ID’yi bir isim veriyoruz.Expiration kısmı ise oluşturduğumuz Token’nın geçerlilik süresini seçiyoruz.Maksimum kullanım zaman 1 yıl olarak seçebiliyoruz.Yetkilendirme olarak gereken yetkileri aşağıdaki gibi verebiliriz.

 

 

 

Test ortamı olduğu için ben Full Access izin vererek oluşturuyorum.

 

 

 

19.Token oluştu.Oluşan Token’ı kopyalayıp PowerShell’e yapıştırıyoruz.

 

 

 

20.Token ID’yi girdikten sonra otomatik olarak agent servis ayarlarını yapıyor.

 

 

 

21.Son olarak agent’ın yükleme yerini kontrol ediyoruz.Eğer bu klasör oluşmuş ise yükleme işlemi ve Token işlemleri başarı ile yapılmıştır.

 

 

 

22.Token durumu aktif olarak görüyoruz.

 

 

23.Şimdi On-Prem yapımızdaki bir IIS Sunucu’ya deployment yapacağımız için Azure DevOps üzerinde bir adet build Pipeline oluşturuyoruz.

 

 

 

24.Kod’un bulunduğu kısmı seçiyoruz.Bu ekrana yeni olarak eskiden olmayan Team Foundation Version Control kısmı eklendi.Projeyi oluşturduğumuz zamanda Team Foundation Version Control seçmiştik.Eğer isterseniz yine de klasik editörü de kullanabilirsiniz.

 

 

 

25.Uygulamamızın bulunduğu konumu seçerek devam ediyoruz.

 

 

 

26.Daha sonra uygulamamızın kullanacağı Template’i seçiyoruz.Bu template’I yazmış olduğumuz uygulamanın türüne göre seçmeyi unutmayınız.

 

 

 

27.Oluşan yükleme Task’larını kaydedip devam ediyoruz.

 

 

 

 

28.Şimdi otomatize olacak bir adet Release pipeline oluşturuyoruz.

 

 

 

29.Stage (aşama) kısımlarında kullanılacak olan template seçiyoruz. Burada On-Prem yapımızdaki IIS Sunucu’ya kuracağımız için IIS website deployment’I seçiyoruz.

 

 

 

30.Oluşturduğumuz Stage’e (Aşama)’ya bir isim veriyoruz.Ben test ortamı olduğu için direk test diyerek isimlendirdim.

 

 

 

31.Oluşan Stage’in içerisindeki Task kısmına girerek devam ediyoruz.Bu ekranda yayınlanacak web sayfası için gerekli olan ayarları yapılandırabilirsiniz.

 

 

 

32. Bu ekran da deployment için kullanacağımız IIS Pool’u seçiyoruz.Bu Pool On-Prem yapımızdaki IIS Sunucusu olarak düşünebiliriz.

 

 

 

 

33.Bu ekranda da On-Prem IIS Sunucu içerisinde deploy edilecek dosya yolunu seçerek devam ediyoruz.

 

 

 

34.Yaptığımız tüm işlemleri kaydederek devam ediyoruz.

 

 

 

35.Sonra artifact ekliyoruz.Artifact uygulamanın Derlenmiş/Build edilmiş hali diyebiliriz.Bu ekranda artifact paketimizi ve kullanılacak olan versiyonlama bilgilerini girdikten sonra kaydedip devam ediyoruz.

 

 

 

36.Daha sonrasında işaretli alanı tıklayarak trigger (Tetikleme) ‘yi aktif ediyoruz.Otomatik olarak deployment işlemini yapabilmek için bu gereklidir.Bunun faydası olarak kodu geliştirirken attığımız her check in’de otomatik olarak kodu’umuz Azure DevOps üzerinden deploy ediliyor.

Tüm bu işlemlerin hepsini kaydederek devam ediyoruz.

 

 

37.Daha sonrasında Build paneli içerisinde Trigger (Tetikleyiciler) altından da Continuous Integration’I aktif ediyoruz.Daha sonra bu işlemi kaydedip devam ediyoruz.

 

 

38.Şimdi yaptığımız tüm ayarları test etmek için bir adet check’in atıyoruz.

 

 

39.Build aşamamız başladı.

 

 

40.Build sürecini bu ekranlardan kontrol edebilirsiniz.

 

 

 

41.Release sürecimi başlamıştır.

 

 

 

 

42.Release sürecimiz bitmiştir.

 

 

 

43.Yapmış olduğumuz deployment On-Prem yapımızdaki IIS Sunucumuz üzerine gelmiştir.

 

 

Bir sonraki yazımda görüşmek üzere.

BeğenFavori PaylaşYorum yap

Yazılım Gündemi - 5 (05-11 Ağustos 2019)

< Önceki Gündem     |   5-11 Ağustos 2019   |     Sonraki Gündem >

GitHub Actions artık CI/CD süreçlerini destekliyor

GitHub 8 Ağustos tarihinde kendi ofislerinde bir etkinlik gerçekleştirdi. Etkinlik aynı zamanda canlı olarak YouTube üzerinden de yayınlandı. Etkinliğin asıl amacı yeni bir ürün/hizmet duyurmaktı fakat öncesinde GitHub'ın bu yıl boyunca yaptığı şeylerin bir özetini geçtiler. Yayın başında hemen duyursalar etkinlikler biterdi çünkü :). GitHub için 2019 yılı böyle geçiyormuş:

Etkinlikte söylememişler doğal olarak ama bir de Amerika'nın ambargo uyguladığı ülkelerde yaşayan geliştiricilerin kodlarına el koyulması olayı var. Yazılım Gündemi - 3 yazısında detaylıca anlatmıştım.

Gelelim etkinlikte tanıtılan yeni özelliğe: GitHub Actions servisi artık Continuous Integration ve Continuous Deployment süreçlerini destekliyor. Yani artık bu süreçleri işletebilmek için travis-ci vb. gibi servisler yerine direkt GitHub içindeki Actions servisi ile yapabilecekmişiz. Bazı özellikleri şu şekilde:

  • Matrix builds ile projenizin birden çok sürümünü aynı anda test etme,
  • Canlı log kayıtları,
  • Kod yazar gibi Action yazabilme

Live logs stream your workflow as it happens.

Canlı log izleme özelliği

Diğer özellikler için konu başlığına eklediğim bağlantıya tıklayabilirsiniz. GitHub Actions henüz beta olduğu için bu özellikleri kullanabilmeniz için Beta'ya kayıt yapmanız gerekiyor: https://github.com/features/actions.

PHP topluluğundaki gruplar ve P++ meselesi

Bu hafta PHP Wiki'sinde yayınlanan sayfaya göre PHP topluluğunda iki grup varmış. İlk grup, PHP'nin geçmişten gelen bazı özellikleri ve bakış açılarını terk etmesi gerektiğini, daha kesin tiplendirilmiş bir dil olması gerektiğini; diğer grup ise PHP'nin geçmişten gelen felsefesini ve özelliklerini korumak gerektiğini savunuyor. Elbette böyle bir tartışmada "doğru" ya da "yanlış" taraf yok. Herkesin kendine göre haklı nedenleri var.

P++'da tam olarak bu nedenden dolayı yapılmak istenen bir PHP lehçesi. Aklımıza ilk geldiği gibi bir PHP 'fork'lanması, takımların ve projelerin ayrılması durumu henüz söz konusu değil yani. P++ henüz bir kod ismi, kesin olarak bu isim belirlenmedi ama bence bir kere bu şekilde duyurulduysa böyle devam edecektir. P++, bildiğimiz PHP'ye göre çok daha sıkı kuralları olan ve farklı özelliklere sahip bir lehçe olacak gibi duruyor. P++ dosyalarını işaretlemek için şöyle bir yöntem önerilmiş:

<?p++?>
<?php echo "Merhaba TeknoSeyir!" ?>

PHP mail grubunda ve Reddit gibi platformlarda tartışmalar devam ediyor. Bakalım ne olacak…

Diğer Haberler

Bir sonraki hafta görüşmek üzere,
Kendinize iyi bakın...

---

Yazılımın herhangi bir alanı ile ilgili karşılaştığınız haberlerle gündeme katkı sağlamak isterseniz #YazılımGündemineMalzeme etiketini kullanabilirsiniz.

BeğenFavori PaylaşYorum yap

DevOps Nedir?

Merhaba

Bu yazım da Güncel, Teknolojik ve herkes tarafında konuşulan DevOps kavramında kısaca bir özet şeklinde bahsedeceğim ve bir sonraki yazım da DevOps sürecine örnek olması açısından Azure DevOps ile ilgili bir örnek uygulama dağıtım yaşam döngüsünü anlatacağım.

DevOps kavramının tarihçesinden çok neler yapmamıza imkan tanıdığından bahsetmek daha doğru olacaktır.

DevOps , Bilgi Teknolojileri departmanı içerisinde bulunan iki temel birimi (Developers and Operations) Geliştiriciler(Yazılım Geliştiriciler, Yazılım Testçileri, vb.), Operasyon (Sistem Mimari ve Altyapı Ekipleri,Güvenlik ve Ağ ekipleri vb.) bir arada etkili bir iletişim içerisinde beraber çalışmalarıdır.DevOps’u aslında bir felsefe, yaklaşım veya bakış açısı olarak değerlendirebiliriz.Yazılım geliştiricilerin alışık olduğu Scrum, Agile, Kanban ve diğer yöntemler gibidir.

 

 

Aşağıdaki resimi açıklayacak olursak,

 

 

Dev takımı,

Oluşturulacak uygulamaya ait planları yapmak,

Uygulamayı oluşturmak(Kodlamak)

Uygulama release ve publish (versiyonlama ve yayınlama)

Uygulama iyileştirme (Update)

Uygulama Test süreçleri

……

Sorumludur.

 

Ops takımı,

Oluşan uygulamaların barındırılacağı ve kullanılacağı ortamı tasarlamak,

Uygulamaların çalışması için gereken sistem bileşenleri ile iletişime geçebilmeleri için gerekli ağ ve güvenlik yapılandırmalarının yapılmasını sağlamak,

Uygulamanın kaynak kullanımını belirlemek,

Uygulamanın gerekli izleme (Monitoring) araçları ile takibini sağlamak,

Uygulamanın sistem kaynaklarını kullanım düzeyine göre kaynak arttırımını sağlamak (Scale Up ve Scale Down) ,

……

Sorumludur.

 

Yukarıda belirttiğim takımların birbirleriyle yaptığı çalışmalar ve iletişim yoğunluğu sayesinde devreye alınması gereken yenilik ve düzeltmeler çok kısa süre içinde işleme alındıkları için verim ve başarı yüksek oluyor.CI&CD (Sürekli entegrasyon ve Sürekli Dağıtım) mantığı DevOps kavramı ile beraber oluşmaktadır.Ortaya çıkarılan ürünlerin bir otomasyon çevresinde ilerlemesi Dağıtım (Deploy), Versiyonlama (Release) ve Test süreçleri olarak DevOps içerisindeki tüm personelin uygulamanın kodlanmasından çalıştırılmasına ve yaşam döngüsünden haberi olmasını sağlıyor.

Yazılım geliştirme sektöründe olan diğer meslek arkadaşlarının ekleyeceği birden fazla düşünce bakış açısı vardır.DevOps felsefesi tüm BT sektörü için daha güncel ve zamana uygun şekilde modernize olmuş hali ile hayatımız da ve sektörümüzde yer alıyor.Bu felsefe ve iş yapış türüne adapte olmak bize yeni olan tüm teknolojiler ile daha hızlı tanışmamızı ve adapte olmamızı sağlıyor.Tüm bu süreç topluluğuna ise DevOps deniyor..

BeğenFavori PaylaşYorum yap

AZURE DEVOPS NEDİR ? VE NASIL KULLANILIR ? -1

Merhaba

Bu yazım da sizlere Azure DevOps platformundan bahsedeceğim.DevOps kavramına ait bilgiyi bir önceki yazımdan edinebilirsiniz.Azure DevOps bize Microsoft’un sağlamış olduğu DevOps süreçlerini düzenli ve pratik olarak gerçekleştirmemizi sağlayan platformdur.Azure DevOps bizlere uygulama yazarken sağlamış olduğu tüm otomasyonel araçlar, kod kütüphaneleri ve daha birçok araçlar ile daha hızlı ve başarılı ilerleyen kolay süreçler yönetmemizi sağlıyor.

 

Azure DevOps ile;

Tüm CI&CD (Sürekli Entegrasyon ve Sürekli Dağıtım) süreçlerimizi yönetebilir,

Süreçlerimizi planlayabilir,

Test aşamalarımızı oluşturabilir,

Geliştirici araçlarını kullanabilir,

Ve daha birçok sürecimizi ve uygulamamızı yönetebiliriz.

 

 

Şimdi Azure DevOps sürecini anlatan bir uygulama konuyu anlatacağım.

 

1.Azure DevOps’u kullanabilmek için bir adet Microsoft Azure DevOps Hesabına sahip olmanız gerekmektedir.

 

https://azure.microsoft.com/tr-tr/services/devops/ bağlantısı üzerinden platforma giriş yapıyoruz.

 

 

 

2.Azure DevOps ana ekranı aşağıdaki gibidir.Azure DevOps üzerinde bir proje oluşturarak sürecimize başlıyoruz.

 

 

 

3.Yeni bir proje oluşturmaya başlıyoruz.

 

Projemizi bir isim veriyoruz,

 

Oluşturacağımız proje internet ortamına açık herkes tarafından ulaşılabilir bir proje ise Public

 

Eğer bizim belirlediğimiz ve izin verdiğimiz kişiler bazında ileryeceksek Private olarak seçiyoruz.

 

Biz Private olarak devam ediyoruz.

 

Projenin versiyon kontrollemesinin yapılmasını Git üzerinden veya Team Foundation üzerinden yapabiliriz.

 

Çalışma türü olarak Proje Yönetimi’nden aşina kişilerin veya yazılım geliştirme süreçlerinde kullanılan Çevik Yöntem (Agile,Scrum) Vb. Seçebilirsiniz.

 

Tüm seçimlerimizi yaptıktan sonra “Create Project” diyerek projemizi oluşturuyoruz.

 

 

 

4.Projemiz başarı ile oluştu.Şimdi Visual Studio üzerinden bir uygulama oluşturmaya başlayabiliriz.

 

 

 

5.Visual Studio’içerisinde bulunan Team Explorer içerisindeki Manage Connections kısmına gelerek Visual Studio’yu Azure DevOps hesabımıza bağlıyoruz.

 

 

 

6.Azure DevOps hesabımızla giriş yaptıktan sonra bağlanmak istediğimiz projemizi seçerek devam ediyoruz.

 

 

 

7.Hesabımız Azure DevOps üzerine başarılı bir şekilde bağlandı.Buradan projemizi Local Bilgisayar’da bulunacağı dosya yolunu belirleyebiliriz.

 

 

 

8.Visual Studio üzerinde yeni bir Web projesi oluşturuyoruz.Ben örnek olmasından açısında Web Projesi seçtim siz farklı bir proje oluşturabilirsiniz.

 

 

 

 

9. Projemizin oluşmasını bekliyoruz.

 

 

 

10.Uygulamamız başarı ile oluştu.Şimdi oluşan bu uygulamamızı DevOps süreçlerine dahil etmemiz için Solution Explorer üzerinden bir Source Control (Kaynak Kontrolü) ekliyoruz.Bu sayede uygulama üzerinde yapılan tüm değişiklikleri Azure DevOps üzerine aktarabileceğiz.

 

 

Makalenin ikinci kısmında uygulamamızı Azure DevOps üzerine nasıl aktaracağımızı anlatacağım.

 

https://endergumen.com/azure-devops-nedir-ve-nasil-kullanilir-2/

BeğenFavori PaylaşYorum yap

AZURE DEVOPS NEDİR ? VE NASIL KULLANILIR ? -2

Bir önceki yazımda https://endergumen.com/azure-devops-kullanimi/ Azure DevOps Nedir ? ve Nasıl Kullanılır ? ile Azure DevOps sürecinin ilk kısmından bahsetttim şimdi makelenin ikinci kısmı ile devam ediyoruz.

 

1. “Add Solution to Source Control” diyerek ekleme işlemini başlatıyoruz.

 

 

 

2.Azure DevOps üzerinde bulunan Projemizi ekleyerek devam ediyoruz.

 

 

 

 

 

3.Source Control’ü ekledikten sonra tüm klasörlerin yanında bulunan yeni değişiklik simgesi olan yeşil “+” işareti oluştu.Bu işaret kaynak dosya veya klasör içerisinde yeni bir şey eklediğinde oluşur.

 

 

 

4.Yapılan değişikliklerin versiyonlanmaları için Check’in dediğimiz kontrol noktalarını eklemek ve yapılan değişiklikleri Azure DevOps üzerinden oluşturduğumuz projeye göndermek için Pending Changes kısmına geliyoruz.

 

 

 

5.Yapacağımız Check’in işlemi için bir isim veriyoruz.Include Changes altında bulunan 50 tane değişiklikleri görüyoruz.Check In diyerek Local Bilgisayar üzerinden geliştirdiğimiz projemizi Azure DevOps üzerine taşımış oluyoruz.

 

 

 

Değişiklik yapılacağına istinaden uyarı ekranı onaylayarak devam ediyoruz.

 

 

 

6.Check In işlemi başarı ile bitmiştir.Şimdi uygulamamızın Azure DevOps üzerine gelmiş mi kontrolünü yapıyoruz.

 

 

 

 

7.Uygulamamız Azure DevOps üzerine gelmiş gözüküyor.Bundan sonra yapılacak tüm değişiklikler Visual Studio üzerinde bağlamış olduğumuz Proje üzerine aktarılacaktır.

 

 

 

8.Dağıtıma Hazırlamış olduğumuz Web Sitemizi / Uygulamamızı Azure üzerinde App Services üzerinden yayınlamaya başlıyoruz.

 

Azure Portal üzerinden App Services üzerinde yeni bir App Service oluşturmaya başlıyoruz.

 

 

 

9.Web App seçerek devam ediyoruz.

 

 

 

10. Create diyerek oluşturmaya başlıyoruz.

 

 

 

11.

Uygulamamıza bir isim veriyoruz,

 

Uygulamanın çalışacağı aboneliği seçiyoruz,

 

Kaynak grubumuzu belirliyoruz,

 

Ardından uygulamanın çalışacağı bir service plan oluşturacağız.Service Plan IIS sunucu / Hosting Sunucu gibi düşünebilirsiniz.

 

 

 

12.Oluşturduğumuz App Service Plan’nın ismini ve lokasyonunu belirliyoruz.Ardından ücretlendirme aşamasını belirliyoruz.

 

 

 

Bu aşamada birden fazla konfigürasyona ve kaynağa sahip sunucu bulunmaktadır.Uygulamanızın kaynak gereksinimine istinaden belirleyebilirsiniz.Biz test ortamı olduğu için ücretsiz olan Dev / Test seçeneği ile devam ediyoruz.

 

 

 

Ben F1 Free seçeneği ile devam ediyorum.

 

 

 

13.Bu ekranda gerekli seçimleri yaparak App Service Plan’ı oluşturuyoruz.Ayrıca yazdığınız uygulama Linux veya Docker service planlar üzerinde yapacaksınız gerekli tercihleri bu ekranda yapabilirsiniz.

 

 

 

 

14.Son kontrollerimiz ardından oluşturma işlemini başlatıyoruz.

 

 

 

 

15.App Service üzerinde oluşturduğumuz Uygulamamızı görüyoruz.

 

 

 

16. Web uygulamamızın durumunu içine girerek kontrol edebilir ve yapılandırma değişiklikleri yapabilirsiniz.

 

 

 

17.Şimdi yazdığımız uygulamayı bir dağıtım ve geliştirme sürecine dahil edeceğiz.Bu süreç topluluğuna Azure DevOps üzerinde PipeLine olarak isimlendiriliyor.New pipeline diyerek sürecimizi başlatıyoruz.

 

 

 

 

18.Geliştirdiğimiz uygulamaların bulunduğu kütüphaneyi seçiyoruz.Bizim uygulamamız seçeneklerden birinin içinde olmadığı için “Use the visual designer” seçeneği ile devam ediyoruz.

 

 

 

19.Biz Team Foundation Version Control kullandığımız için TFVC seçeneğini seçiyoruz ve uygulamamızın bulunan kök dosyayı seçiyoruz.

 

 

 

 

20.Gerekli seçimleri yaptıktan sonra geliştirdiğimiz uygulama için gerekli template’leri seçmek için devam ediyoruz.

 

 

 

21.Biz ASP.NET web uygulaması geliştirdiğimiz için ASP.NET template’ini seçiyoruz.Bu ekranda bulunan template’ler geliştirdiğiniz uygulamanın derlenmesi için gerekli olan araçları barındırıyor.Onun için uygulamanıza uyan template’i seçmeniz daha sağlıklı olacaktır.

 

 

 

 

 

22.Bu aşamada uygulamanın derleneceği sunucuyu seçerek devam ediyoruz.Bu ekranda uygulamanın sln uzantısını ve oluşacak artifact dosyasının adını belirliyoruz.

 

Artifact’i uygulamanın dağıtıma hazır hale getirilmiş versiyonu olarak düşünebiliriz.

 

 

 

23.Sonrasında oluşturduğumuz uygulamanın bulunduğu dizin yolunu seçiyoruz.

 

 

 

 

 

24.Uygulamamızı manuel olarak derlemek için Save & queue kısmından Queue’ya gelerek manuel derleme işlemini başlatıyoruz.

 

Not:Azure DevOps süreci içerisinde derleme ve versiyonlama işlemlerini otomatik yapmayı yazının ilerleyen kısımlarında bahsedeceğim.

 

 

 

25.Uygulamanın Build süreci (Derleme Süreci) başlamıştır.Bu ekranda uygulamanın tüm derleme süreçlerini gözlemleyebiliriz.Bu derlemeyi yaparken Agent pool olarak seçtiğimiz VM üzerinde yapıyor.Bu VM Azure DevOps’un sağlamış olduğu bizim kontrolümüz dışında olan tamamen Azure DevOps’un yönettiği ve tek kullanımlık olarak çalışıp kapanan bir VM’dir ve Ücretsizdir.

 

Tek makine ücretsiz olup aynı anda iki derleme yapılamaz eğer yapılmak istenirse ikinci derleme makinesini satın almanız gerekir.

 

 

 

26.Uygulamamızın derlemesi (Build) bitti.Artifact kısmından uygulamanın sunucuya konulacak dağıtılacak sürümü edinebiliriz.Oluşan artifact dosyasını kendi IIS sunucumuza veya App service plan’a yükleyebiliriz.App Service plana Kudu üzerinden erişim sağlayıp değişiklikleri yapabilirsiniz.

 

 

 

27.İlk Check In’inin Manuel Build (Derleme) süreci bitmiş oldu.

 

 

 

Şimdi bu süreci otomatik olarak nasıl yapabiliriz yapılan değişiklikleri hızlı ve stabil şekilde production ortama nasıl aktarırızdan makalenin diğer kısmında bahsedeceğim.

 

https://endergumen.com/azure-devops-nedir-ve-nasil-kullanilir-3/

BeğenFavori PaylaşYorum yap

AZURE DEVOPS NEDİR ? VE NASIL KULLANILIR ? -3

Bir önceki yazımda https://endergumen.com/azure-devops-kullanimi/ Azure DevOps Nedir ? ve Nasıl Kullanılır ?

 

https://endergumen.com/azure-devops-nedir-ve-nasil-kullanilir-2/ Azure DevOps Nedir ? ve Nasıl Kullanılır ? -2

 

 Azure DevOps sürecinin ilk ve ikinci kısımlarından bahsetttim şimdi makelenin üçüncü kısmı ile devam ediyoruz.

 

1. Şimdi Release sürecini (Versiyonlama) otomatize etmek için yeni bir release pipeline oluşturuyoruz.

 

 

 

2.Burada birbirine takip eden süreçleri oluşturacağız.Süreç oluşturma adımlarını yapabilmek için Stages kısmına stage’ler ekleyerek (Aşama) yapıyoruz.Uygulama üzerinde yapmış olduğumuz değişikliklerin hangi sistem üzerine deploy edileceğini sağ tarafta bulunan template’lerden birini seçerek devam edebilirsiniz.

 

Ben Azure App Service Plan kullandığım için resimdeki seçenek ile devam ediyorum.

 

 

 

 

3.Stage oluşturmaya devam ediyoruz.Oluşan stage’e bir isim veriyoruz.Örnek verecek olursak Test süreci ve Production olarak düşünebiliriz.Her Check In işleminden sonra otomatik olarak test sürecine girer ve test süreci onaylanırsa otomatik olarak Production süreci başlar ve uygulama deploy edilmiş olur.

 

 

Buradaki süreçleri istersek manuel bir onay mekanizmasına bağlarız istersek de otomatik bir onay mekanizmasından geçirerek production’a alabiliriz.Burada yapınızı ve proje göre değişiklik gösterebilir.

 

 

 

4.Aynı adımları Production aşaması içinde yaparak devam ediyoruz.

 

 

 

5.Stages süreçleri bitmiş bulunuyor şimdi bu sürece istinaden Artifacts ekleyeceğiz.Yani uygulamamızı bu sürece dahil edeceğiz.

 

 

 

6.Uygulamamızı bu ekranda ekliyoruz.Artifact paketi olarak hangi versiyonu kullanacaksak onu seçiyoruz ben son versiyonu kullanıyorum.Genel de son versiyon kullanılır farklı bir durum için farklı seçimler yapabilirsiniz.

 

 

 

7.Artifact ekledik.

 

 

 

8.Artifact’i ekledikten sonra CD süreci için bir tetikleme ekleyeceğiz.

 

 

 

 

9.Şimdi Stages sürecine geri dönüyoruz.Burada Stage’lerin kullanacakları App Service Planları seçeceğiz.Fakat burada test ortamı olduğu için tek App Service kullanılmıştır.Siz canlı bir ortamda her stage için farklı App Service’ler veya App Service Plan’lar oluşturabilirsiniz.

 

Bu ekranda Azure Hesap bilgilerimizi tanımlayarak istediğimiz App Service’i seçerek devam ediyoruz.

 

 

 

10.Aynı işlemi Production Stage’i içinde yapıyoruz.

 

 

 

11.Son durum aşağıdaki gibidir.

 

 

 

12.Şimdi Onaylama sürecinden bahsedeceğim. Tüm bu Stage’leri istersek bir onay mekanizmasından geçirebiliriz veya otomatik olarak devam etmesini sağlayabiliriz.Eğer onay istersek Post-deployment approvals seçeneğini aktif edebilirsiniz.

 

 

 

13.Onay verecek kullanıcıyı seçiyoruz. Timeout kısmı ise eğer Onay belirlenmiş süre kadar gelmezse süreci iptal edilir.

 

 

 

14.Yaptığımız tüm değişikleri kaydediyoruz.

 

 

 

 

 

15.Şimdi CI (Sürekli Entegrasyon) sürecini etkinleştiriyoruz.Bu süreç’de her check in işleminden sonra otomatik olarak uygulamanın tekrardan derlenip canlıya alınmasını sağlar.

 

 

 

16.Uygulamamızın dosya yolunu seçip continuous integration sürecini etkinleştiriyoruz.

 

 

 

17.Yaptığımız değişiklikleri kaydederek devam ediyoruz.

 

 

 

 

 

18.Şimdi tüm DevOps sürecinin otomatik olarak nasıl işlediğini görebilmek için bilgisayarımda bulunan Web uygulamam üzerinde bir değişiklik yapıcam ve Check In yaptıktan sonra nasıl Production ortamı güncellenecek ona bakacağız.

 

Şuan uygulamamız bu şekilde.

 

 

 

19.Kod tarafında değişikliği yaptım.Şimdi Team Explorer içindeki Pending Changes altını kontrol edeceğiz.

 

 

 

20.Yaptığım değişiklikler burada görülüyor şimdi bu değişikliği canlı ortama taşıyacağım. Herhangi bir onay mekanizması kullanmadığım için beklentim tüm sürecin gerçekleşmesi ve tarayıcı yenileyince otomatik olarak değişikliğin uygulandığını görmek.

 

 

 

21.Check In yapıldı şimdi Azure DevOps üzerinde Build (Derleme) işlemini kontrol edeceğiz.

 

 

 

22.Derleme Build sürecimiz başlamış.Sürecin üzerine tıklayıp içine giriyoruz.

 

 

 

23.Derleme işlemimiz seçmiş olduğunuz Hosted Agent üzerinde başladı.

 

 

 

24.Test sürecimiz başarı ile bitti.1 Warning olan kısım ise Test Stage’i içine bir test yazılımı eklemediğimiz içindir.Test dosyasını bulamadığı için uyarı vermiştir.

 

 

 

25.Şimdi Azure DevOps üzerinde Release sürecini kontrol ediyoruz.Uygulamanın versiyonlama sürecine girdiğini görüyoruz.Kontrol etmek için tıklayıp içine giriyoruz.

 

 

 

26.Stage’lerin süreçleri başlatılmış görünüyor.

 

 

 

27.Tüm Stage süreci bitmiş oldu.

 

 

 

 

28.Ve yaptığımız değişiklik canlı ortama yansımış Azure DevOps üzerinden CI&CD sürecimiz bitmiştir.

 

 

 

Bir sonraki yazım da görüşmek üzere..

BeğenFavori PaylaşYorum yap