Sürekli Entegrasyon - Hızlı Kılavuz

Sürekli Entegrasyon ilk olarak 2000 yılında olarak bilinen yazılımla tanıtıldı. Cruise Control. Yıllar geçtikçe, Sürekli Entegrasyon herhangi bir yazılım organizasyonunda temel bir uygulama haline geldi. Bu, geliştirme ekiplerine, bir yazılım programında yapılan her kod değişikliği için bir derleme ve sonraki testlerin gerçekleştirilmesini sağlamaya çağıran bir geliştirme uygulamasıdır. Bu kavram, derleme yaşam döngüsünde sorunların geç oluşumlarını bulma sorununu ortadan kaldırmayı amaçlıyordu. İzolasyon içinde çalışan ve yeterince entegre olmayan geliştiricilerin yerine, kod değişikliklerinin ve yapılarının asla tek başına yapılmamasını sağlamak için Sürekli Entegrasyon tanıtıldı.

Neden Sürekli Entegrasyon?

Sürekli entegrasyon, herhangi bir yazılım geliştirme sürecinin çok ayrılmaz bir parçası haline geldi. Sürekli Entegrasyon süreci, yazılım geliştirme ekibi için aşağıdaki soruların yanıtlanmasına yardımcı olur.

• Tüm yazılım bileşenleri olması gerektiği gibi birlikte çalışıyor mu? - Bazen sistemler o kadar karmaşık hale gelebilir ki, her bileşen için birden fazla arabirim olabilir. Bu gibi durumlarda, tüm yazılım bileşenlerinin birbiriyle sorunsuz çalışmasını sağlamak her zaman çok önemlidir.

• Kod, entegrasyon amaçları için çok mu karmaşık? - Sürekli entegrasyon süreci başarısız olmaya devam ederse, kodun çok karmaşık olma ihtimali olabilir. Ve bu, kodu daha az karmaşık ve daha sürdürülebilir hale getirmek için uygun tasarım modellerinin uygulanması için bir sinyal olabilir.

• Kod, belirlenmiş kodlama standartlarına uygun mu? - Test senaryolarının çoğu her zaman kodun doğru kodlama standartlarına uygunluğunu kontrol eder. Otomatik derlemeden sonra otomatik bir test yaparak, bu, kodun istenen tüm kodlama standartlarını karşılayıp karşılamadığını kontrol etmek için iyi bir noktadır.

• Otomatik testler ne kadar kod kapsamına girer? - Test senaryoları kodun gerekli işlevselliğini kapsamıyorsa, kodun test edilmesinin bir anlamı yoktur. Bu nedenle, yazılan test senaryolarının uygulamanın tüm temel senaryolarını kapsamasını sağlamak her zaman iyi bir uygulamadır.

• Son değişiklikten sonra tüm testler başarılı oldu mu? - Bir test başarısız olursa, o zaman kodun konuşlandırılmasına devam etmenin bir anlamı yoktur, bu nedenle kodun dağıtım aşamasına geçmeye hazır olup olmadığını kontrol etmek için iyi bir noktadır.

İş akışı

Aşağıdaki görüntü, tüm Sürekli Entegrasyon iş akışının herhangi bir yazılım geliştirme projesinde nasıl çalıştığına dair hızlı bir iş akışını gösterir. Buna sonraki bölümlerde ayrıntılı olarak bakacağız.

Dolayısıyla, yukarıdaki iş akışına dayalı olarak, bu genellikle sürekli entegrasyon süreci nasıl işler.

• İlk olarak, bir geliştirici kodu sürüm kontrol havuzuna işler. Bu arada, entegrasyon oluşturma makinesindeki Sürekli Entegrasyon sunucusu, değişiklikler için kaynak kodu havuzunu sorgular (örneğin, birkaç dakikada bir).

• Bir kesinleştirme gerçekleştikten hemen sonra, Sürekli Entegrasyon sunucusu, sürüm kontrol havuzunda değişikliklerin meydana geldiğini algılar, böylece Sürekli Entegrasyon sunucusu kodun en son kopyasını depodan alır ve ardından yazılımı entegre eden bir yapı betiğini yürütür.

• Sürekli Entegrasyon sunucusu, derleme sonuçlarını belirtilen proje üyelerine e-postayla göndererek geri bildirim üretir.

• Daha sonra, o projenin inşası başarılı olursa birim testleri gerçekleştirilir. Testler başarılı olursa, kod hazırlama veya üretim sunucusuna dağıtılmaya hazırdır.

• Sürekli Entegrasyon sunucusu, sürüm kontrol havuzundaki değişiklikleri sorgulamaya devam eder ve tüm süreç tekrarlanır.

Yazılım bölümü, herhangi bir Sürekli Entegrasyon sürecinin en önemli yönüdür. Bu bölüm, Sürekli Entegrasyon sürecinin tamamı için ihtiyaç duyulacak yazılıma odaklanmaktadır.

Kaynak Kod Deposu

Kaynak kodu deposu, tüm kaynak kodunu ve üzerinde yapılan tüm değişiklikleri korumak için kullanılır. Kaynak kodu deposu yönetimi için en popüler iki yöntem, alt sürüm ve Git'tir ve Git en yeni popüler sistemdir. Şimdi sisteme Git'in nasıl kurulacağına bakacağız.

sistem gereksinimleri

Hafıza	2 GB RAM (önerilir)
Disk alanı	Kurulum için 200 MB HDD. Proje kaynak kodunu depolamak için ek depolama gerekir ve bu, eklenen kaynak koduna bağlıdır.
İşletim Sistemi Sürümü	Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X üzerine kurulabilir.

Git yükleniyor

Step 1 - Git için resmi web sitesi https://git-scm.com/. Bağlantıya tıklarsanız, aşağıdaki ekran görüntüsünde gösterildiği gibi Git resmi web sitesinin ana sayfasına gideceksiniz.

Step 2 - Git'i indirmek için ekranı aşağı kaydırın ve İndirilenler bölümüne gidin ve İndirilenler'i tıklayın.

Step 3 - Windows bağlantısını tıklayın ve Git için indirme işlemi otomatik olarak başlayacaktır.

Step 4- Git için indirilen .exe dosyasına tıklayın. Bizim durumumuzda Git-2.6.1-64-bit.exe dosyasını kullanıyoruz. Bir sonraki ekranda görünen Çalıştır'ı tıklayın.

Step 5 - Aşağıdaki ekranda görünen İleri düğmesine tıklayın.

Step 6 - Genel Lisans sözleşmesini kabul etmek için aşağıdaki ekranda İleri'yi tıklayın.

Step 7 - Git kurulumunuzun konumunu seçin.

Step 8 - Kurulması gereken varsayılan bileşenleri kabul etmek için İleri'yi tıklayın.

Step 9 - Git'i Windows'tan kullanacağımız için 'Windows komut isteminden Git'i kullan' seçeneğini seçin.

Step 10 - Aşağıdaki ekranda, varsayılan 'Checkout Windows-style, Unix-style line endings commit' ayarını kabul edin ve Next'i tıklayın.

Step 11 - Git'in yüklenmesi için sistem olarak Windows'u kullandığımız için aşağıdaki ekranda 'Windows varsayılan konsol penceresini kullan' seçeneğini seçin.

Kurulum şimdi başlayacak ve kurulum tamamlandıktan sonra Git'i yapılandırmak için sonraki adımlar takip edilebilir.

Git'i Yapılandırma

Git kurulduktan sonra, Git'in ilk yapılandırması için yapılandırma adımlarının gerçekleştirilmesi gerekir.

Yapılması gereken ilk şey, kimliği Git'te yapılandırmak ve ardından bir kullanıcı adı ve e-posta yapılandırmaktır. Bu önemlidir çünkü her biriGit commitbu bilgiyi kullanır ve oluşturmaya başladığınız taahhütlere değişmez bir şekilde eklenir. Bunu komut istemini açıp ardından aşağıdaki komutları girerek yapabilirsiniz -

git config –global user.name “Username”
git config –global user.email “emailid”

Aşağıdaki ekran görüntüsü daha iyi anlamak için bir örnektir.

Bu komutlar aslında Git'in konfigürasyon dosyasını buna göre değiştirecektir. Ayarlarınızın etkili olmasını sağlamak için, aşağıdaki komutu vererek Git yapılandırma dosyasının ayarlarını listeleyebilirsiniz.

git config --list

Çıktının bir örneği aşağıdaki ekran görüntüsünde gösterilmektedir.

Sürekli Entegrasyon Sunucusu

Tüm sürekli entegrasyon hattı için gerekli olan bir sonraki önemli yazılım, Sürekli Entegrasyon yazılımının kendisidir. Endüstride en sık kullanılan Sürekli Entegrasyon yazılımları aşağıdadır -

• Jenkins- Bu, birçok geliştirme topluluğu tarafından kullanılan açık kaynaklı bir Sürekli Entegrasyon yazılımıdır.

• Jet Brains TeamCity - Bu, mevcut en popüler ticari Sürekli Entegrasyon yazılımlarından biridir ve çoğu şirket bunu Sürekli Entegrasyon ihtiyaçları için kullanır.

• Atlassian Bamboo- Bu, Atlassian Pvt adlı bir şirket tarafından sağlanan bir başka popüler Sürekli Entegrasyon yazılımıdır. Ltd.

Yukarıda bahsedilen tüm yazılımlar Sürekli Entegrasyon için aynı model üzerinde çalışmaktadır. Bu eğitimin amacı için, bakacağızJetbrains TeamCity Sürekli Entegrasyon sunucusu için.

TeamCity Kurulumu

Aşağıda, Jet Brains TeamCity'yi bilgisayarınıza kurmak için adımlar ve sistem gereksinimleri yer almaktadır.

sistem gereksinimleri

Hafıza	4 GB RAM (önerilir)
Disk alanı	Kurulum için 1 GB HDD. Her proje için derleme çalışma alanını depolamak için ek depolama gereklidir.
İşletim Sistemi Sürümü	Windows, Linux, Mac OS X üzerine kurulabilir.

Kurulum

Step 1 - TeamCity için resmi web sitesihttps://www.jetbrains.com/teamcity/. Verilen bağlantıya tıklarsanız, aşağıdaki ekran görüntüsünde gösterildiği gibi TeamCity resmi web sitesinin ana sayfasına gideceksiniz. TeamCity için gerekli yazılımı indirmek için sayfaya göz atabilirsiniz.

Step 2 - İndirilen .exe, yürütme amacıyla kullanılıyor TeamCity-9.1.6.exe. Yürütülebilir dosyayı çift tıklayın ve ardından açılan sonraki ekranda Çalıştır'ı tıklayın.

Step 3 - Kurulumu başlatmak için İleri'yi tıklayın.

Step 4 - Lisans sözleşmesini kabul etmek ve kuruluma devam etmek için 'Kabul Ediyorum' düğmesine tıklayın.

Step 5 - Kurulumun konumunu seçin ve İleri'ye tıklayın.

Step 6 - Kurulum için varsayılan bileşenleri seçin ve İleri'ye tıklayın

Bu, kurulum sürecini başlatacaktır. Tamamlandığında, yapılandırma süreci takip edecektir.

Step 7- Sunucunun çalıştırması için bir bağlantı noktası numarası seçin. En iyisi, aşağıdaki gibi farklı bir bağlantı noktası kullanmaktır8080.

Step 8- Daha sonra TeamCity'nin hangi hesapta çalışması gerektiğini soracaktır. SYSTEM hesabını seçin ve İleri'ye tıklayın.

Step 9- Ardından, başlatılması gereken hizmetleri soracaktır. Varsayılanları kabul edin ve ardından İleri'ye tıklayın.

TeamCity'yi Yapılandırma

Kurulum tamamlandıktan sonra, sonraki adım TeamCity'nin yapılandırılmasıdır. Bu yazılım, tarayıcıda aşağıdaki URL'ye göz atılarak açılabilir -

http://locahost:8080

Step 1- İlk adım, TeamCity tarafından gerçekleştirilecek olan yapıların yerini sağlamaktır. İstediğiniz konumu seçin ve Devam Et düğmesine tıklayın.

Step 2- Sonraki adım, tüm TeamCity eserlerini depolamak için veri tabanını belirlemektir. Öğreticinin amacı için, biri seçilebilirInternal (HSQLDB), ürünleri test amacıyla kullanırken en uygun olan dahili bir veritabanıdır.

TeamCity daha sonra onu kurmak ve çalıştırmak için gerekli tüm adımları işleyecektir.

Step 3- Ardından, lisans sözleşmesini Kabul etmeniz istenecektir. Aynısını kabul edin ve Devam'ı tıklayın.

Step 4- TeamCity yazılımında oturum açmak için kullanılacak bir yönetici hesabı oluşturmanız gerekir. Gerekli ayrıntıları girin ve 'Hesap Oluştur' düğmesini tıklayın.

Şimdi TeamCity'de oturum açacaksınız.

Derleme Aracı

Oluşturma aracı, programın belirli bir şekilde oluşturulmasını sağlayan bir araçtır. Araç, normalde programın düzgün bir şekilde oluşturulması için gerekli olan görevlerin bir listesini gerçekleştirecektir. Örneğimizden beri, bir.Net program bakacağız MSBuildinşa aracı olarak. MSBuild aracı, projeyi oluşturmak için kullanılan görevlerin listesini içeren bir yapı dosyasına bakar. Bir web yapılandırma projesi için tipik bir Yapı dosyasına bakalım.

Aşağıdakiler, Derleme dosyasının dikkate alınması gereken temel bölümleridir.

IIS Ayarları

Bağlantı noktası numarasının hangisi olduğunu, web sunucusundaki yolun ne olduğunu ve uygulama çalıştırıldığında ne tür kimlik doğrulaması gerektiğini belirlemek için aşağıdaki ayarlar kullanılır. Bunlar, öğreticide daha sonra dağıtımın nasıl gerçekleştirileceğini öğrendiğimizde MSBuild komutu aracılığıyla değiştirilecek olan önemli ayarlardır.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

Bu, Build sunucusuna bu projeyi çalıştırmak için gereken tüm bağımlı ikili dosyaların ne olduğunu söylemek için kullanılır.

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

.Net Framework Sürümü

TargetFrameworkVersionprojenin çalışması için mevcut olması gereken .Net sürümünün hangisi olduğunu söyler. Bu kesinlikle gereklidir, çünkü yapı sunucusunda buna sahip değilse, yapı başarısız olur.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Dağıtım Ortamı - Amazon

Bu öğreticinin amacı doğrultusunda, Sürekli Entegrasyon sunucumuzun uygulamamızı Amazon'a dağıtma becerisine sahip olmasını sağlayacağız. Bunun için aşağıdaki eserlerin yerinde olduğundan emin olmamız gerekiyor.

Veritabanı sunucusu

Veritabanı sunucusunun dağıtım için Amazon'da yerinde olduğundan emin olmak için aşağıdaki adımları uygulayın.

Step 1 - Amazon Konsoluna gidin - https://aws.amazon.com/console/.

Kimlik bilgilerinizle giriş yapın. Amazon sitesinde ücretsiz bir kimlik başvurusunda bulunabileceğinizi unutmayın; bu, Amazon'daki bazı kaynakları ücretsiz olarak kullanmanıza izin veren ücretsiz bir katmana sahip olmanızı sağlar.

Step 2 - Veritabanınızı oluşturmak için RDS Bölümüne gidin.

Step 3 - Açılan sonraki ekranda Örnekler'i tıklayın.

Step 4 - tıklayın Launch DB Açılan sonraki ekranda seçeneği.

Step 5 - SQL Server sekmesini seçin ve ardından SQL Server Express için Seç seçeneğini seçin.

Step 6 - Amazon'da bulunan ücretsiz veritabanı katmanını kullandığınızı onaylamak için aşağıdaki ayrıntıların girildiğinden emin olun.

Step 7 - Tüm alanlar doldurulduktan sonra Sonraki Adım düğmesini tıklayın.

Step 8 - Açılan bir sonraki ekranda, tüm varsayılan ayarları kabul edin ve Launch DB Instance.

Step 9- Daha sonra, DB'nin başarıyla başlatıldığını belirten bir ekran karşınıza çıkacaktır. Aynı sayfada, Veritabanı Kurulumu'nu görüntülemek için bir düğme olacaktır. Görmek için bağlantıya tıklayınDB Instance kuruluyor.

Bir süre sonra, yukarıdaki ekranın durumu DB Eşgörünümünün başarıyla oluşturulduğunu bildirmek için değişecektir.

Web sunucusu

Bir sonraki adım, web uygulamasını barındıracak olan Amazon'da web sunucunuzu oluşturmaktır. Bu, bunu yerine getirmek için sonraki adımları izleyerek yapılabilir.

Step 1 - Amazon Konsoluna gidin - https://aws.amazon.com/console/.

Kimlik bilgilerinizle giriş yapın. Başvuru yapabileceğinizi unutmayın.free id on the Amazon siteBu, Amazon'daki kaynakların bir kısmını ücretsiz olarak kullanmanıza izin veren ücretsiz bir katmana sahip olmanızı sağlar.

Step 2 - Şuraya git EC2 section web sunucunuzu oluşturmak için.

Step 3 - Sonraki ekranda Örneği Başlat'ı tıklayın.

Step 4 - Windows'u tıklayın - Microsoft Windows Server 2010 R2 Base.

Step 5 - seçin t2.microücretsiz katmanın bir parçası olan seçenek. TıklayınNext: Configure Instance Details.

Step 6 - Açılan bir sonraki ekranda varsayılan ayarları kabul edin ve ardından seçeneği seçin Next: Add Storage.

Step 7 - Sonraki ekranda varsayılan ayarları kabul edin ve seçeneği seçin Next: Tag Instance.

Step 8 - Sonraki ekranda varsayılan ayarları kabul edin ve aşağıdaki seçeneği seçin Next: Configure Security Group.

Step 9 - Sonraki ekranda varsayılan ayarları kabul edin ve aşağıdaki seçeneği seçin Review and Launch.

Step 10 - Açılan sonraki ekranda Başlat'ı tıklayın.

Step 11- Açılan bir sonraki ekranda bir anahtar çifti oluşturmanız istenecektir. Bu, daha sonraki bir zamanda sunucuda oturum açmak için kullanılacaktır. Sadece anahtar çiftini oluşturun ve tıklayınLaunch Instance.

Örnek şimdi Amazon'da kurulacak.

Bir projede işlerin ters gitme ihtimali vardır. CI'yi etkili bir şekilde uygulayarak, proje geliştirme döngüsüne girdiğinde daha sonra değil, yol boyunca her adımda ne olduğunu öğrenirsiniz. CI, ortaya çıktıklarında riskleri tanımlamanıza ve azaltmanıza yardımcı olarak, somut kanıtlara dayanarak projenin sağlığını değerlendirmeyi ve raporlamayı kolaylaştırır.

Bu bölüm, Sürekli Entegrasyon kullanılarak önlenebilecek risklere odaklanacaktır.

Herhangi bir projede yönetilmesi gereken birçok risk vardır. Geliştirme yaşam döngüsünün erken aşamalarında riskleri ortadan kaldırarak, bu risklerin daha sonra, sistem gerçekten hayata geçtiğinde sorunlara dönüşme şansı daha azdır.

Risk 1 - Kurulabilir Yazılım Eksikliği

“It works on my machine but does not work on another”- Bu muhtemelen herhangi bir yazılım organizasyonunda karşılaşılan en yaygın ifadelerden biridir. Yazılımda günlük olarak yapılan değişikliklerin sayısı nedeniyle, bazen yazılım yapısının gerçekten çalışıp çalışmadığına dair çok az güven vardır. Bu endişenin aşağıdaki üç yan etkisi vardır.

• Yazılımı inşa edip edemeyeceğimize çok az güveniyor veya hiç güvenmiyoruz.

• Yazılımı dahili olarak (yani, test ekibi) veya harici olarak (yani, müşteri) teslim etmeden önceki uzun entegrasyon aşamaları, bu süre zarfında başka hiçbir şey yapılmaz.

• Test edilebilir yapıları üretememe ve yeniden üretememe.

Çözüm

IDE ile derleme süreçleri arasındaki sıkı bağlantıyı ortadan kaldırır. Yalnızca yazılımı entegre etmek için ayrı bir makine kullanın. Yazılımı oluşturmak için ihtiyacınız olan her şeyin sürüm kontrol havuzunda bulunduğundan emin olun. Son olarak, bir Sürekli Entegrasyon sistemi oluşturun.

Sürekli Entegrasyon sunucusu, sürüm kontrol havuzundaki değişiklikleri izleyebilir ve depoda bir değişiklik algıladığında proje oluşturma komut dosyasını çalıştırabilir. Sürekli Entegrasyon sisteminin kapasitesi, yapının testlerden geçmesini, incelemelerin gerçekleştirilmesini ve yazılımın geliştirme ve test ortamlarında konuşlandırılmasını içerecek şekilde artırılabilir; bu şekilde her zaman çalışan bir yazılıma sahip olursunuz.

“Inability to synchronize with the database”- Bazen geliştiriciler, geliştirme sırasında veritabanını hızlı bir şekilde yeniden oluşturamaz ve bu nedenle değişiklik yapmakta zorlanır. Genellikle bu, veritabanı ekibi ile geliştirme ekibi arasındaki bir ayrılıktan kaynaklanır. Her ekip kendi sorumluluklarına odaklanacak ve birbirleri arasında çok az işbirliği olacak. Bu endişenin aşağıdaki üç yan etkisi vardır:

• Veritabanında veya kaynak kodunda değişiklik yapma veya yeniden düzenleme korkusu.

• Veritabanını farklı test verileri kümeleriyle doldurmada zorluk.

• Geliştirme ve test ortamlarının (ör. Geliştirme, Entegrasyon, Kalite Güvencesi ve Test) sürdürülmesinde zorluk.

Çözüm

Yukarıdaki sorunun çözümü, tüm veritabanı yapılarının sürüm kontrol havuzuna yerleştirilmesinin gerçekleştirilmesini sağlamaktır. Bu, veritabanı şemasını ve verilerini yeniden oluşturmak için gereken her şey anlamına gelir: veritabanı oluşturma komut dosyaları, veri işleme komut dosyaları, depolanmış prosedürler, tetikleyiciler ve diğer veritabanı varlıklarına ihtiyaç vardır.

Veritabanınızı ve tablolarınızı bırakıp yeniden oluşturarak, derleme komut dosyanızdaki veritabanını ve verileri yeniden oluşturun. Ardından, depolanan prosedürleri ve tetikleyicileri uygulayın ve son olarak test verilerini ekleyin.

Veritabanınızı test edin (ve inceleyin). Genellikle, veri tabanını ve verileri test etmek için bileşen testlerini kullanırsınız. Bazı durumlarda, veritabanına özgü testler yazmanız gerekir.

Risk 2 - Kusurları Yaşam Döngüsünün Geç Keşfi

Kaynak kodda birden fazla geliştirici tarafından sık sık meydana gelen çok fazla değişiklik olduğundan, kodda yalnızca daha sonraki bir aşamada tespit edilebilecek bir kusurun ortaya çıkma ihtimali her zaman vardır. Bu gibi durumlarda, bu büyük bir etkiye neden olabilir çünkü yazılımda hata ne kadar geç tespit edilirse, hatayı ortadan kaldırmak o kadar pahalı hale gelir.

Çözüm

Regression Testing- Bu, herhangi bir yazılım geliştirme döngüsünün en önemli yönüdür, tekrar test edin ve test edin. Yazılım kodunda büyük bir değişiklik varsa, tüm testlerin çalıştırıldığından emin olmak kesinlikle zorunludur. Ve bu, Sürekli Entegrasyon sunucusunun yardımıyla otomatik hale getirilebilir.

Test Coverage- Test senaryoları kodun tüm işlevselliğini kapsamıyorsa test etmenin bir anlamı yoktur. Uygulamayı test etmek için oluşturulan test senaryolarının eksiksiz olduğundan ve tüm kod yollarının test edildiğinden emin olmak önemlidir.

Örneğin, test edilmesi gereken bir giriş ekranınız varsa, başarılı bir giriş senaryosuna sahip bir test senaryosuna sahip olamazsınız. Bir kullanıcının farklı bir kullanıcı adı ve şifre kombinasyonu girdiği ve ardından bu tür senaryolarda ne olduğunu görmeniz gereken negatif bir test senaryosuna sahip olmanız gerekir.

Risk 3 - Proje Görünürlüğünün Olmaması

Manuel iletişim mekanizmaları, proje bilgilerinin doğru kişilere zamanında dağıtılmasını sağlamak için çok fazla koordinasyon gerektirir. Yanınızdaki geliştiriciye eğilmek ve onlara en son derlemenin ortak drive'da olduğunu bildirmek oldukça etkili, ancak çok iyi ölçeklenmiyor.

Ya bu bilgiye ihtiyaç duyan başka geliştiriciler varsa ve onlar ara veriyorsa veya başka bir şekilde müsait değilse? Bir sunucu çökerse, nasıl bilgilendirilirsiniz? Bazıları, manuel olarak bir e-posta göndererek bu riski azaltabileceklerine inanıyor. Ancak bu, bilginin doğru zamanda doğru kişilere iletilmesini garanti edemez çünkü yanlışlıkla ilgili tarafları dışarıda bırakabilirsiniz ve bazıları o anda e-postalarına erişemeyebilir.

Çözüm

Bu sorunun çözümü yine Sürekli Entegrasyon sunucusudur. Tüm CI sunucuları, derlemeler başarısız olduğunda tetiklenecek otomatik e-postalara sahip olma özelliğine sahiptir. Tüm kilit paydaşlara gönderilen bu otomatik bildirim ile, herkesin yazılımın mevcut durumu hakkında bilgi sahibi olması da sağlanır.

Risk 4 - Düşük Kaliteli Yazılım

Kusurlar var ve sonra potansiyel kusurlar var. Yazılımınız iyi tasarlanmadığında veya proje standartlarına uymadığında veya bakımı karmaşık olduğunda potansiyel kusurlarınız olabilir. Bazen insanlar buna kod veya tasarım kokuları diyor - "bir şeylerin yanlış olabileceğinin bir belirtisi."

Bazıları, düşük kaliteli yazılımın yalnızca ertelenmiş bir proje maliyeti (teslimattan sonra) olduğuna inanıyor. Ertelenmiş bir proje maliyeti olabilir, ancak yazılımı kullanıcılara teslim etmeden önce başka birçok soruna da yol açar. Aşırı karmaşık kod, mimariyi takip etmeyen kod ve yinelenen kod - bunların tümü genellikle yazılımda kusurlara yol açar. Bu kodu ve tasarım kokularını kusurlara dönüşmeden önce bulmak hem zamandan hem de paradan tasarruf sağlayabilir ve daha yüksek kaliteli yazılımlara yol açabilir.

Çözüm

CI yazılımı ile entegre edilebilen bir kod kalitesi kontrolü yapmak için yazılım bileşenleri vardır. Bu, kodun gerçekten uygun kodlama yönergelerine uyduğundan emin olmak için kod oluşturulduktan sonra çalıştırılabilir.

Kaynak kontrolü, kaynak kodu yönetim sistemleri veya revizyon kontrol sistemleri olarak da bilinen sürüm kontrol sistemleri, dosyalarınızın birden çok sürümünü saklamaya yönelik bir mekanizmadır, böylece bir dosyayı değiştirdiğinizde önceki revizyonlara erişebilirsiniz.

İlk popüler sürüm kontrol sistemi, adı verilen tescilli bir UNIX aracıydı SCCS1970'lere kadar uzanan (Kaynak Kod Kontrol Sistemi). Bunun yerini aldıRCSRevizyon Kontrol Sistemi ve daha sonra CVS, Eşzamanlı Sürümler Sistemi.

Şimdi kullanılan en popüler sürüm kontrol sistemi Subversion ve Git. İlk önce neden bir sürüm kontrol sistemi kullanmamız gerektiğine bakalım ve sonra kaynak kodumuzu yerleştirmeye bakalım.Git source code repository system.

Sürüm Kontrol Sisteminin Amacı

Kaynak kontrolü yerine sürüm kontrolü terimini kullanmamızın bir nedeni, sürüm kontrolünün sadece kaynak kodu için olmamasıdır. Yazılımınızın oluşturulmasıyla ilgili her bir yapı, sürüm kontrolü altında olmalıdır.

Developers should use it for source code - Varsayılan olarak tüm kaynak kodun sürüm oluşturma kontrol sisteminde depolanması gerekir

Related artefacts- Her sistem, veritabanı komut dosyaları, derleme ve dağıtım komut dosyaları, belgeler, kitaplıklar ve uygulamanız için yapılandırma dosyaları, derleyiciniz ve araç koleksiyonunuz gibi kaynak kodla ilgili yapılara sahip olacaktır. Bunların tümü, tüm geliştirme ve dağıtım sürecini tamamlar ve ayrıca sürüm oluşturma kontrol sisteminde depolanması gerekir.

Uygulama için tüm bilgileri kaynak kontrolünde depolayarak, uygulamanızın üzerinde çalıştığı test ve üretim ortamlarını yeniden oluşturmak daha kolay hale gelir. Bu, uygulamanızın yazılım yığını ve ortamı oluşturan işletim sistemleri, DNS Bölge Dosyaları, Güvenlik Duvarı Yapılandırması vb. İçin yapılandırma bilgilerini içermelidir.

En azından, uygulamanızın ikili dosyalarını ve çalıştıkları ortamları yeniden oluşturmak için gereken her şeye ihtiyacınız var. Amaç, projenin yaşamının herhangi bir noktasında muhtemelen değişebilecek her şeyin kontrollü bir şekilde depolanmasını sağlamaktır. Bu, proje geçmişinin herhangi bir noktasında geliştirme ortamından üretim ortamına kadar tüm sistemin durumunun tam bir anlık görüntüsünü kurtarmanıza olanak tanır.

Ekipteki herkesin aynı ayarları kullanmasını kolaylaştırdığından, geliştirme ekibinin geliştirme ortamları için yapılandırma dosyalarını sürüm kontrolünde tutmak bile yararlıdır. Analistler ihtiyaç belgelerini saklamalıdır. Test uzmanları, test komut dosyalarını ve prosedürlerini sürüm kontrolünde tutmalıdır. Proje yöneticileri sürüm planlarını, ilerleme çizelgelerini ve risk günlüklerini buraya kaydetmelidir.

Kısacası ekibin her üyesi projeyle ilgili her türlü belge veya dosyayı sürüm kontrolünde saklamalıdır.

Kaynak Kodu Sürüm Oluşturma Kontrol Sistemi için Git ile Çalışma

Bu bölüm şimdi Git'in bir versiyonlama kontrol sistemi olarak nasıl kullanılabileceğine odaklanacaktır. Kodunuzu sürüm kontrol sistemine nasıl yükleyebileceğinize ve içindeki değişiklikleri nasıl yönetebileceğinize odaklanacaktır.

Demo Uygulamamız

Tüm bu eğitimin amacı için basit bir Web ASP.NetTüm Sürekli Entegrasyon Süreci için kullanılacak uygulama. Bu alıştırma için tüm kod ayrıntılarına odaklanmamıza gerek yok, sadece projenin ne yaptığına dair genel bir bakışa sahip olmak, tüm sürekli entegrasyon sürecini anlamak için yeterli. Bu .Net uygulaması,Visual Studio Integrated Development Environment.

Aşağıdaki ekran görüntüsü, Visual Studio ortamındaki çözümün yapısıdır. Ana koda sahip olan çok basit bir Web uygulamasıdır.Demo.aspx dosya.

Demo.aspx dosyasındaki kod aşağıdaki programda gösterilir -

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

Kod çok basittir ve tarayıcıya "Sürekli Entegrasyon" dizesini çıkarır.

Projeyi Google Chrome'da çalıştırdığınızda, çıktı aşağıdaki ekran görüntüsünde gösterildiği gibi olacaktır.

Kaynak Kodunu Git'e Taşıma

Kaynak kodunu komut satırı arayüzünden Git'e nasıl taşıyacağımızı göstereceğiz, böylece Git'in nasıl kullanılacağına dair bilgi son kullanıcı için daha net olacaktır.

Step 1 - Başlat Git Repository. Komut istemine gidin, proje klasörünüze gidin ve komutu veringit init. Bu komut, havuza yüklenmesi gerektiğinde Git tarafından tanınabilmesi için gerekli Git dosyalarını proje klasörüne ekleyecektir.

Step 2- Git deposuna eklenmesi gereken dosyalarınızı eklemek. Bu, yayınlayarak yapılabilir.git add command. Nokta seçeneği Git'e proje klasöründeki tüm dosyaların Git deposuna eklenmesi gerektiğini söyler.

Step 3- Son adım, proje dosyalarını Git deposuna kaydetmektir. Bu adım, tüm dosyaların artık Git'in bir parçası olmasını sağlamak için gereklidir. Verilecek komut aşağıdaki ekran görüntüsünde verilmiştir. –m option dosyaların yüklenmesine bir yorum sağlamaktır.

Çözümünüz artık Git'te mevcuttur.

Aşağıda, Sürekli Entegrasyon için temel özelliklerden veya uygulamalardan bazıları verilmiştir.

• Maintain a single source repository- Tüm kaynak kodu tek bir depoda tutulur. Bu, kaynak kodun birden çok konuma dağılmasını önler. Gibi araçlarSubversion and Git kaynak kodunu korumak için en popüler araçlardır.

• Automate the build- Yazılımın oluşturulması otomatikleştirilebilecek şekilde yapılmalıdır. Gerçekleştirilmesi gereken birden fazla adım varsa, inşa aracının bunu yapabilmesi gerekir. .Net için MSBuild varsayılan oluşturma aracıdır ve Java tabanlı uygulamalar için aşağıdaki gibi araçlara sahipsinizMaven and Grunt.

• Make your build self-testing- Yapı test edilebilir olmalıdır. Derleme gerçekleştikten hemen sonra, yazılımın çeşitli işlevselliği için test yapılabilmesini sağlamak için test senaryoları çalıştırılmalıdır.

• Every commit should build on an integration machine- Entegrasyon makinesi, yapım sunucusudur ve yapının bu makinede çalışması sağlanmalıdır. Bu, tüm bağımlı bileşenlerin Sürekli Tümleştirme sunucusunda bulunması gerektiği anlamına gelir.

• Keep the build fast- Oluşturma dakikalar içinde gerçekleşmelidir. Derlemenin gerçekleşmesi saatler sürmemelidir, çünkü bu, derleme adımlarının doğru şekilde yapılandırılmadığı anlamına gelir.

• Test in a clone of the production environment- İnşa ortamı doğası gereği üretim ortamına yakın olmalıdır. Bu ortamlar arasında büyük farklar varsa, o zaman yapının, yapı sunucusuna geçmesine rağmen üretimde başarısız olabileceği bir durum olabilir.

• Everyone can see what is happening - Tüm oluşturma, test etme ve dağıtım süreci herkes tarafından görülebilir olmalıdır.

• Automate deployment- Sürekli Entegrasyon, Sürekli dağıtıma yol açar. Yapının bir aşamalandırma veya üretim ortamına dağıtılmasının kolay olmasını sağlamak kesinlikle gereklidir.

Sürekli Entegrasyon için en önemli gereksinimlerin listesi aşağıdadır.

• Check-In Regularly- Sürekli entegrasyonun düzgün çalışması için en önemli uygulama, kaynak kodu havuzunun ana hattına veya ana hattına sık sık yapılan kontrollerdir. Kod girişi günde en az birkaç kez yapılmalıdır. Düzenli olarak check-in yapmak birçok başka fayda sağlar. Değişiklikleri küçültür ve dolayısıyla yapıyı bozma olasılığını azaltır. Bu, yazılımın geri dönülecek en son sürümünün, sonraki herhangi bir derlemede bir hata yapıldığında bilinmesi anlamına gelir.

  Ayrıca, kodu yeniden düzenleme konusunda daha disiplinli olmaya ve davranışı koruyan küçük değişikliklere bağlı kalmaya yardımcı olur. Çok sayıda dosyayı değiştiren değişikliklerin diğer insanların çalışmalarıyla çelişme olasılığının düşük olmasını sağlamaya yardımcı olur. Geliştiricilerin daha keşfedici olmalarına, fikirleri denemelerine ve son taahhüt edilen sürüme geri dönerek onları atmalarına olanak tanır.

• Create a Comprehensive Automated Test Suite- Kapsamlı bir otomatik test paketiniz yoksa, başarılı bir yapı yalnızca uygulamanın derlenebileceği ve birleştirilebileceği anlamına gelir. Bazı ekipler için bu büyük bir adım olsa da, uygulamanızın gerçekten çalıştığına dair güven sağlamak için belirli düzeyde otomatik testlere sahip olmak çok önemlidir.

  Normalde Sürekli Entegrasyonda yapılan 3 tip test vardır: unit tests, component tests, ve acceptance tests.

  Birim testleri, uygulamanızın küçük parçalarının davranışını ayrı ayrı test etmek için yazılır. Genellikle tüm uygulamayı başlatmadan çalıştırılabilirler. Veritabanına (uygulamanızda varsa), dosya sistemine veya ağa isabet etmezler. Uygulamanızın üretim benzeri bir ortamda çalışmasını gerektirmezler. Birim testleri çok hızlı çalışmalıdır - tüm paketiniz, büyük bir uygulama için bile, on dakikadan daha kısa bir sürede çalışabilmelidir.

  Bileşen testleri, uygulamanızın çeşitli bileşenlerinin davranışını test eder. Birim testleri gibi, her zaman tüm uygulamanın başlatılmasını gerektirmezler. Ancak, veritabanına, dosya sistemine veya diğer sistemlere çarpabilirler (bunlar kapatılabilir). Bileşen testlerinin çalıştırılması genellikle daha uzun sürer.

• Keep the Build and Test Process Short - Kodu oluşturmak ve birim testlerini çalıştırmak çok uzun sürerse, aşağıdaki sorunlarla karşılaşırsınız.

  • İnsanlar tam bir derleme yapmayı bırakacak ve check-in yapmadan önce testleri çalıştıracak. Daha başarısız yapılar almaya başlayacaksınız.

  • Sürekli Entegrasyon süreci o kadar uzun sürer ki, siz yapıyı tekrar çalıştırabildiğiniz zaman birden fazla kaydetme gerçekleşmiş olur, böylece hangi girişin yapıyı bozduğunu bilemezsiniz.

  • İnsanlar daha az check-in yapacaklar çünkü yazılımın oluşturulmasını ve testlerin çalışmasını beklemek için yaşları boyunca oturmak zorunda kalıyorlar.

• Don’t Check-In on a Broken Build- Sürekli entegrasyonun en büyük hatası, bozuk bir yapıyı kontrol etmektir. Derleme bozulursa, sorumlu geliştiriciler onu düzeltmeyi bekler. Kırılmanın nedenini mümkün olan en kısa sürede tespit edip düzeltiyorlar. Bu stratejiyi benimsersek, kırılmaya neyin sebep olduğunu bulmak ve derhal düzeltmek için her zaman en iyi konumda olacağız.

  İş arkadaşlarımızdan biri bir check-in yaptıysa ve sonuç olarak yapıyı bozduysa, en iyi tamir şansına sahip olmak için, sorunu net bir şekilde çözmeye ihtiyaçları olacaktır. Bu kural ihlal edildiğinde, yapının düzeltilmesi kaçınılmaz olarak çok daha uzun sürer. İnsanlar yapının bozuk olduğunu görmeye alışırlar ve çok hızlı bir şekilde yapının her zaman bozuk kaldığı bir duruma girersiniz.

• Always Run All Commit Tests Locally Before Committing- Uygulama için tasarlanan testlerin CI sunucusunda çalıştırılmadan önce yerel bir makinede çalıştırıldığından her zaman emin olun. Bu, doğru test senaryolarının yazıldığından emin olmak içindir ve CI sürecinde herhangi bir başarısızlık varsa, bunun nedeni başarısız test sonuçlarıdır.

• Take Responsibility for All Breakages that Result from Your Changes- Bir değişiklik yaparsanız ve yazdığınız tüm testler geçerse, ancak diğerleri bozulursa, yapı hala bozuktur. Genellikle bu, uygulamaya bir gerileme hatası oluşturduğunuz anlamına gelir. Değişikliklerinizin sonucu olarak geçmeyen tüm testleri düzeltmek sizin sorumluluğunuzdadır - değişikliği siz yaptınız. CI bağlamında bu açık görünmektedir, ancak aslında pek çok projede yaygın bir uygulama değildir.

Çeşitli programlama dilleri için kullanılabilen çeşitli oluşturma araçları vardır. En popüler derleme araçlarından bazıları şunlardır:Ant for Java ve MSBuild for .NET. Özel bir kabuk veya toplu komut dosyaları kümesi yerine, özellikle yazılım oluşturmak için tasarlanmış bir komut dosyası oluşturma aracı kullanmak, tutarlı, tekrarlanabilir bir derleme çözümü geliştirmenin en etkili yoludur.

Öyleyse başlamak için neden bir inşa sürecine ihtiyacımız var? Yeni başlayanlar için, bir Sürekli Entegrasyon sunucusu için, oluşturma işleminin çalışması kolay olmalı ve uygulanması sorunsuz olmalıdır.

Bir yapı dosyasının .Net için nasıl görünebileceğine dair basit bir örnek alalım -

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

Yukarıdaki kod hakkında aşağıdaki hususlara dikkat edilmesi gerekir -

• Yapı adıyla bir hedef belirtildi. Burada hedef, bir inşa sürecinde gerçekleştirilmesi gereken mantıksal adımların bir koleksiyonudur. Birden fazla hedefiniz olabilir ve hedefler arasında bağımlılıklarınız olabilir.

• Hedefimizde, inşa süreci başladığında gösterilecek bir seçenek mesajı tutuyoruz.

• MSBuild task hangi .Net projesinin oluşturulması gerektiğini belirtmek için kullanılır.

Yukarıdaki örnek, çok basit bir yapı dosyası durumudur. Sürekli Entegrasyonda, tüm oluşturma sürecinin sorunsuz olmasını sağlamak için bu dosyanın güncel tutulması sağlanır.

NET'te Çözüm Oluşturmak

.Net için varsayılan derleme aracı MSBuild'dir ve .Net çerçevesiyle birlikte gelen bir araçtır. Sisteminizdeki çerçeveye bağlı olarak, ilgili MSbuild sürümüne sahip olacaksınız. Örnek olarak, .Net çerçevesini varsayılan konuma yüklediyseniz,MSBuild.exe dosya aşağıdaki konumda -

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Örnek projemizi nasıl inşa edebileceğimize bir bakalım. Örnek projemizin adlı bir klasörde bulunduğunu varsayalım.C:\Demo\Simple.

Yukarıdaki çözümü oluşturmak için MSBuild'i kullanmak için, komut istemini açmamız ve aşağıdaki programda gösterildiği gibi MSBuild seçeneğini kullanmamız gerekir.

msbuild C:\Demo\Simple\Simple.csproj

Yukarıdaki örnekte, csprojNet'e özel proje dosyasıdır. Csproj dosyası, yazılımın düzgün bir şekilde oluşturulması için gerekli bilgilerin mevcut olduğundan emin olmak için tüm ilgili bilgileri içerir. MSBuild komutunun çıktısının ekran görüntüsü aşağıdadır.

Derleme başarılı olduğu ve hata olmadığı sürece çıktı uyarıları için endişelenmenize gerek yoktur.

Şimdi ne anlama geldiğini görmek için MSBuild dosyasının belirli yönlerine bakalım. Bu hususlar, Sürekli Entegrasyon Döngüsünden bilinmesi önemlidir.

Derleme komut dosyaları, tüm sürekli Entegrasyon döngüsünün bir parçası olacak çözümü oluşturmak için kullanılır. Visual Studio'nun bir parçası olarak oluşturulan genel yapı betiğine bakalım..Netörnek çözümümüz için. Derleme betiği, basit bir çözüm için bile oldukça büyüktür, bu yüzden onun en önemli kısımlarından geçeceğiz. Varsayılan olarak, derleme komut dosyası, Visual Studio'daki ana çözümle aynı ada sahip bir dosyada depolanır. Yani bizim durumumuzda, dosyayı açarsanızSimple.csprojçözümü oluşturmak için kullanılacak tüm ayarları göreceksiniz.

• Kullanılan MSBuild sürümüne bağımlılık - Aşağıdaki ayarlar, CI sunucusunda yüklü MSBuild dosyalarını kullanacaktır.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

• Çözümü doğru bir şekilde oluşturmak için hangi dosyalar gereklidir? ItemGroupetiketi, projenin başarıyla oluşturulması için gerekli olan tüm gerekli .Net dosyalarını içerecektir. Bu dosyaların buna göre derleme sunucusunda bulunması gerekecektir.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

• Kullanılacak Web sunucusu ayarları nelerdir - Sürekli Dağıtım konusunu ziyaret ettiğimizde, MSBuild'in bu ayarları geçersiz kılmak ve bunu tercih ettiğimiz sunucuya dağıtmak için nasıl kullanılacağını göreceksiniz.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

Bir sonraki önemli adım, çözümün derleme sunucusunda oluşturulmasını sağlamaktır. İlk bölüm manuel bir adımdır, çünkü sürekli entegrasyon aracı kullanılmadan önce, derlemenin yapı sunucusunda istemci makinesinde yapılanla aynı şekilde çalıştırıldığından emin olmalıyız. Bunu yapmak için aşağıdaki adımları uygulamalıyız -

Step 1- Tüm çözüm dosyasını sunucuya kopyalayın. Derleme sunucumuz olarak kullanılacak bir Amazon bulut sunucusu oluşturmuştuk. Öyleyse, tüm sunucuya manuel olarak kopyalayın.Net sunucuya çözüm.

Step 2- Çerçevenin sunucuda mevcut olduğundan emin olun. Uygulamanızı istemci makinenizde .Net framework 4.0'da derlediyseniz, sunucu makinesinde de kurulu olduğundan emin olmalısınız. Öyleyse yere gitC:\Windows\Microsoft.NET\Framework sunucunuzda ve istenen çerçevenin mevcut olduğundan emin olun.

Step 3 - Şimdi sunucuda MSBuild'i çalıştıralım ve ne olacağını görelim.

Tamam, görünüşe göre bir hata bulduk. Sürekli Entegrasyonda önemli bir ders vardır ve bu, Derlemenin derleme sunucusunda çalıştığından emin olmanız gerektiğidir. Bunun için tüm ön gereksinim yazılımlarının yapı sunucusuna kurulduğundan emin olmanız gerekir.

.Net için, adında bir bileşen kurmamız gerekiyor Visual Studio Redistributable package. Bu paket, bir program için gerekli olan tüm gerekli dosyaları içerir..Netbir sunucu üzerine inşa etmek için uygulama. Öyleyse, derleme sunucusunda aşağıdaki kurulum adımlarını gerçekleştirelim.

Step 4 - Kurulumu başlatmak için yürütülebilir dosyaya çift tıklayın.

Step 5 - Sonraki adımda, Lisans Koşullarını kabul edin ve Yükle'yi tıklayın.

Step 6 - Şimdi MSBuild'i çalıştırırken, MSBuild'i çağırırken ek bir parametre eklediğimizden emin olmalıyız, bu - p:VisualStudioversion = 12.0. Bu, MSBuild'in önceki adımda indirilen dosyalara başvurmasını sağlar.

Artık çözümün doğru bir şekilde inşa edildiğini görebiliyoruz ve temel projemizin sunucu üzerinde doğru şekilde oluşturulduğunu da biliyoruz.

Bir sonraki önemli husus, temel kodumuzun Git olan kaynak kodu deposu yönetim sunucumuza kontrol edilmesini sağlamaktır. Bunu yapmak için şu adımları izlememiz gerekiyor.

Step 1- Depoyu Git'e yüklenebilmesi için başlatın. Bu,gitinit komutu. Bu yüzden proje klasörünüze gitmeniz vegit init komut.

Step 2- Sonraki adım, Git'te evreleme dosyaları olarak adlandırılır. Bu, Proje klasöründeki Git'e eklenmesi gereken tüm dosyaları hazırlar. Bunu ile yaparsıngit addkomut aşağıdaki ekran görüntüsünde gösterildiği gibi. "." gösterim, dizindeki ve alt dizindeki tüm dosyaların kaydetmeye dahil edilmesi gerektiğini söylemek için kullanılır.

Step 3 - Son adım, dosyaları Git deposuna teslim etmektir, böylece bu artık tam teşekküllü bir Git deposudur.

Artık kaynak kodumuz Git deposunda bulunduğuna ve tüm ilk kodumuz derleme sunucusunda çalıştığına göre, Sürekli Entegrasyon sunucumuzda bir proje oluşturmanın zamanı geldi. Bu, aşağıdaki adımlarla yapılabilir -

Step 1- TeamCity yazılımına giriş yapın. Sürekli Entegrasyon sunucunuzdaki url'ye gidin -http://localhost:8080/login.html.

Yönetici kimlik bilgilerini girin ve sunucuya giriş yapın.

Step 2- Giriş yaptıktan sonra, ana ekran karşınıza çıkacak. TıklayınCreate Project yeni bir projeye başlamak için.

Step 3- Projeye bir isim verin ve projeyi başlatmak için Oluştur'a tıklayın. Bizim durumumuzda aşağıdaki ekran görüntüsünde gösterildiği gibi projemize 'Demo' ismini veriyoruz.

Step 4- Bir sonraki adım, projemizde kullanılacak Git deposundan bahsetmektir. Sürekli Entegrasyon ortamında, CI sunucusunun kodu Git özellikli depodan alması gerektiğini unutmayın. Önceki adımda proje klasörümüzün Git özellikli bir depo olmasını zaten etkinleştirmiştik. TeamCity'de bir VCS kökü oluşturmanız gerekir. Bunun için tıklayınVCS Roots projenin ana ekranında.

Step 5 - Bir sonraki ekranda Create VCS root aşağıdaki ekran görüntüsünde gösterildiği gibi.

Step 6 - Açılan bir sonraki ekranda aşağıdaki adımları uygulayın -

• VCS türünden Git olarak bahsedin.

• VCS kökü için bir isim verin, bu herhangi bir kolay isim olabilir. Adını verdikApp.

• Getirme url'sini olarak verin C:\Demo\Simple - Bu out git etkin havuz.

• Ekranı aşağı kaydırırsanız, bir Test bağlantısı düğmesi görürsünüz. Git'in etkin olduğu depoya başarıyla bağlanabildiğinizden emin olmak için tıklayın.

Step 7 - Oluştur'a tıklayın ve şimdi aşağıdaki resimde gösterildiği gibi deponuzun kaydedildiğini göreceksiniz.

Step 8- Sonraki adım, projeyi oluşturmak için kullanılacak bir yapı yapılandırması oluşturmaktır. İçinde proje ekranınıza gidinTeamCity → General Settings. Derleme Yapılandırması Oluştur'u tıklayın.

Step 9- Aşağıdaki ekranda, Yapı Yapılandırması için bir ad verin. Bizim durumumuzda bunu şöyle adlandırdıkDemoBuild ve ardından Oluştur'a tıklayın.

Step 10 - Açılan bir sonraki ekranda sizden VCS repositoryönceki adımlarda oluşturulmuş. Öyleyse adını seç‘App’ ve Ekle'yi tıklayın.

Step 11- Şimdi açılan bir sonraki ekranda, inşa adımlarını yapılandırmamız gerekiyor. Bu yüzden 'configure build steps manuallyköprü.

Step 12 - Bir sonraki inşa ekranında, aşağıdaki ayrıntıları girmemiz gerekiyor -

• Runner tipini MSBuild olarak seçin.

• Adım adı için isteğe bağlı bir ad verin.

• Oluşturulması gereken dosyanın adını verin. Daha önceki bölümlerde MSbuild'i belirttiğimizde, normalde şu seçeneği verdiğimizi görürüz:Simple.csproj. Aynı şeyin burada da belirtilmesi gerekiyor.

• MSBuild sürümünü 'Microsoft Build Tools 2013' olarak seçin.

• Seç MSBuild ToolsVersion 12.0 olarak.

• Ayarları kaydetmek için sayfayı aşağı kaydırın.

Step 13 - Sonraki ekranda Çalıştır'ı tıklayın.

Uygulamanızın yapısının şimdi devam ettiğini göreceksiniz.

Başarılı bir ekran elde etmelisiniz, bu da çözümünüzün düzgün bir şekilde oluşturulduğunun iyi bir işaretidir.

Aşağıdaki ekran görüntüsünde gösterildiği gibi Sürekli Entegrasyon sunucusu tarafından kapsanan tüm adımları görmek için derleme günlüğünüze de gidebilirsiniz.

Artık Git'te temel kodumuza ve Sürekli Entegrasyon sunucusuna bir bağlantıya sahip olduğumuza göre, artık Sürekli Entegrasyonun ilk adımını iş başında görmenin zamanı geldi. Bu, Sürekli Entegrasyon sunucusunda tetikleyiciler gibi görevler tanımlanarak yapılır ve bu da tüm Sürekli Entegrasyon İşlemini mümkün olduğunca sorunsuz hale getirir. Visual Studio'daki kodumuzda bir değişiklik yapalım.

Step 1 - Şuraya git Demo.aspx Visual Studio'da bir sayfa açın ve sayfanın başlığında bir değişiklik yapın.

Step 2 - Git depomuzu, git status komut, aslında göreceksiniz ki Demo.aspx dosya değiştirildi.

Şimdi, kodumuzdaki her değişikliğin sürekli entegrasyon sunucumuzda bir yapıyı tetiklemesini sağlamamız gerekiyor. Bunun için aşağıdaki değişiklikleri yapmamız gerekiyor.

Step 3 - Proje panonuza gidin ve tetikleyiciler bölümünü tıklayın ve Add new trigger.

Step 4 - Açılan sonraki ekranda şunu seçin: VCS trigger, depoya bir giriş yapıldığında bir yapı tetiklenecek şekilde bir tetikleyici oluşturmak için kullanılacak.

Step 5 - Tıklayın Show Advanced Options ve aşağıdaki ekran görüntüsünde gösterilen seçeneklerin seçildiğinden emin olun.

Step 6- Kaydet'i tıklayın. Aşağıdaki ekran görüntüsünde gösterildiği gibi, tetikleyicinin başarıyla kaydedildiğini göreceksiniz.

Step 7- Şimdi kodumuzu Git deposuna girip ne olacağını görmenin zamanı geldi. Öyleyse komut istemimize gidelim vegit add değiştirdiğimiz dosyaları hazırlamak için komut.

Step 8 - Şimdi yayınlayın git commit komutu ve değişiklikleri Git deposuna gönderecektir.

Step 9 - Şimdi Projelere Genel Bakış ekranınıza giderseniz, şimdi yeni bir yapının tetiklendiğini ve çalıştırıldığını göreceksiniz.

Eğer görürsen Change log Tabgöreceksin git comment bu, yapıyı tetikledi.

Bir kez daha deneyelim. Hadi başka bir değişiklik yapalımDemo.aspxdosya. Hadi birgit add komut ve bir git commit aşağıdaki commit mesajıyla birlikte komut verin.

Şimdi TeamCity'deki Proje panosunda otomatik olarak tetiklenen bir yapının olduğunu göreceksiniz.

Yapı bir başarı mesajı gösterecektir.

Şimdi, değişiklik taahhüt edildiğinde kullanılan 'Second commit' mesajını göreceksiniz. git repository.

Artık Sürekli Entegrasyon sürecinin ilk bölümünü başarıyla tamamladık.

Bir Derleme Hatası Bildirimi, bir derleme başarısız olduğunda tetiklenen bir olaydır. Bir yapı başarısız olduğunda bildirim tüm önemli kişilere gönderilir. Böyle bir durumda yapılacak ilk önemli şey, yapının geçmesini sağlamak için başarısız yapıya zaman harcanmasını sağlamaktır. Aşağıdaki adımlar, derleme bildirimlerinin TeamCity'de yerleştirilmesini sağlamak için kullanılır.

TeamCity'de e-posta bildirimlerini ayarlamak için adımlar aşağıda verilmiştir.

Step 1- TeamCity'de Proje panonuza gidin, sağ üst köşedeki Yönetim'e tıklayın. Sonra göreceksinEmail Notifiersol taraftaki bağlantı. E-posta için genel ayarları getirmek için bu bağlantıya tıklayın.

Step 2 - Sonraki adım, geçerli bir SMTP Server. Gmail, herkes tarafından kullanılabilen ücretsiz bir SMTP olanağı sağlar. Böylece bu ayrıntıları aşağıdaki ekran görüntüsünde gösterildiği gibi gelen bir sonraki ekrana girebiliriz.

• SMTP Ana Bilgisayarı - smtp.gmail.com
• SMTP bağlantı noktası no - 465
• SMTP girişinden e-posta iletileri gönderin - Bu, geçerli bir Gmail kimliği olmalıdır
• SMTP şifresi - Söz konusu Gmail kimliği için geçerli şifre
• Güvenli bağlantı - Bunu SSL olarak koy

Step 3 - Tıklayın Test Connectionsadece ayarların düzgün çalıştığından emin olmak için. Sonra tıklayınSave ayarları kaydetmek için.

Step 4- Sonraki adım, bir kullanıcı için yapı bildirimlerini etkinleştirmektir. İlk görev, bu yapı bildirimlerini alacak bir kullanıcı oluşturmaktır. Proje panonuza gidin veUsers Option.

Step 5- Yeni bir kullanıcı oluşturun. Gerekli kullanıcı adını ve şifreyi girin. Ardından, ekranın alt kısmında yer alan Kullanıcı Oluştur düğmesine tıklayın.

Step 6 - Şimdi bu yeni kullanıcı kimliği ve şifresiyle TeamCity sistemine giriş yapın.

Step 7- Giriş yaptıktan sonra, kullanıcının Genel ayarları ile karşılaşacaksınız. E-posta Bildiricisi bölümünde Düzenle'yi tıklayın.

Step 8 - Açılan sonraki ekranda Add new rule.

Step 9 - Yeni kural ekle'de, aşağıdaki iki seçeneği belirleyin ve ardından Kaydet'i tıklayın.

• Seçili projelerden derlenir - Demo projesini seçin.

• 'Derleme başarısız' onay kutusunu etkinleştirin.

Bu iki seçeneği etkinleştirerek, artık Demo projesi için bir yapı başarısız olduğunda, kullanıcıya bir e-posta bildirimi gönderilecek - demouser.

Step 10- Şimdi bunu çalışırken görmek için yanlış bir yapıyı tetikleyelim. Visual Studio'da şu adrese gidin:demo.aspx.cs dosyalayın ve yanlış bir kod satırı ekleyin.

Step 11 - Şimdi kodu Git'ten kontrol edin git add ve git commit.

Şimdi Proje Panosunda, yapı otomatik olarak tetiklenecek ve aşağıdaki ekran görüntüsünde gösterildiği gibi yapının başarısız olacağını göreceksiniz.

Gmail kimliğine giriş yaparsanız demouser, aslında aşağıdaki ekran görüntüsünde gösterildiği gibi bir yapı hatası bildirimi göreceksiniz.

Sürekli Entegrasyonun temel yönlerinden biri, her zaman yapıların nasıl performans gösterdiğini görmek, önemli ölçütleri toplamak, bu sonuçları belgelemek ve sürekli derlemeler aracılığıyla sürekli geri bildirim oluşturmaktır.

Bu ölçütlere sahip olmanın faydaları nelerdir?

• Not Committing Code Enough- Geliştiriciler bir sürüm kontrol havuzuna sık sık kod göndermiyorsa, bunun nedeni yavaş bir entegrasyon derlemesi olabilir. Derleme süresini azaltmaya başlamak için, darboğazları belirlemek için entegrasyon oluşturma ortamının üst düzey bir analizini gerçekleştirin.

  Daha sonra, bulguları analiz edin ve en uygun iyileştirmeyi belirleyin, ardından derleme süresini azaltmak için derleme sürecinde değişiklikler yapmaya çalışın. Son olarak, daha fazla iyileştirmenin garanti edilip edilmediğini belirlemek için derleme süresini yeniden değerlendirin.

• Improve Test Performance- İyi işleyen bir CI sisteminde bile, entegrasyon oluşturma süresinin büyük bir kısmı otomatik testlerin yürütülmesiyle alınacaktır. Bu testlerin performansının değerlendirilmesi ve iyileştirilmesi, oluşturma süresini önemli ölçüde azaltabilir.

• Infrastructure Issues- Sistem altyapısı nedeniyle entegrasyon yapılarının yavaş olduğunu keşfedebilirsiniz. Ağ performansı yavaş olabilir veya yavaş performans gösteren bir sanal özel ağ bağlantısı vardır.

  Coğrafi olarak dağınık sistemler ve güvenilmez donanım veya yazılımlar da performans sorunlarına neden olabilir. Derleme süresini azaltmak için tüm altyapı kaynaklarını araştırın ve iyileştirin.

Metrikler

Aşağıda, Sürekli Entegrasyon sunucusunda bulunan bazı ölçümler verilmiştir.

TeamCity'nin neler sunabileceğine bakalım -

En basit ölçüm biçimlerinden biri, proje kontrol panelinde bulunanlardır. Buradaki kilit unsur, her derlemenin süresini not etmektir. Her derlemenin süresi, oluşturulan koda göre orantısız bir şekilde artmaya başlarsa, bu bir sorun olabilir. Bu, alınabilecek bir geri bildirimdir ve bunun nedenleri, CI sunucusunun kaynaklarının düşük olması ve belki de sunucunun kapasitesinin artırılması gerekmesi olabilir.

TeamCity, CI sunucusunun aslında altyapı ile ilgili herhangi bir sorun yaşayıp yaşamadığını görme olanağına sahiptir. İçindeadmin dashboard TeamCity'de tıklanabilir Disk Usage her derleme tarafından ne kadar disk alanı tüketildiğini görmek için.

Daha fazla ayrıntı gerekirse, TeamCity'de diagnostics buttonhakkında daha fazla bilgi verebilir CPU and Memory CI Sunucusu tarafından kullanılmaktadır.

Derleme Metriklerinin Ayrıntılı Görünümü

Belirli bir projenin yapılarının zaman içinde ayrıntılı bir görünümünü görmek isterse, bu, proje yapılarının bir parçası olarak kullanılabilir. Proje oluşturma ekranında İstatistikler ekranına gidin, bu, yapının nasıl performans gösterdiğine dair çeşitli istatistikler ve grafikler sağlayacaktır.

Sürekli Entegrasyonun temel özelliklerinden biri, on-going testingCI sunucusu tarafından oluşturulan tüm kodu tutar. CI Sunucusu tarafından bir derleme gerçekleştirildikten sonra, gerekli kodun test edilmesini sağlamak için test senaryolarının yerinde olduğundan emin olunmalıdır. Her bir CI sunucusu, uygulamanın bir parçası olarak birim test durumlarını çalıştırma yeteneğine sahiptir.CI suite. İçinde.Netbirim testi, cihaza yerleşik bir özelliktir. .Net framework ve aynı şey CI Sunucusuna da dahil edilebilir.

Bu bölüm, bir test durumunu nasıl tanımlayabileceğimizi görecek. .Netve derleme tamamlandıktan sonra TeamCity sunucumuzun bu test durumunu çalıştırmasına izin verin. Bunun için öncelikle örnek projemiz için tanımlanmış bir birim testimiz olduğundan emin olmamız gerekiyor.

Bunu yapmak için sonraki adımları son derece dikkatli izlemeliyiz.

Step 1- Birim Testimizde kullanılacak çözümümüze yeni bir sınıf ekleyelim. Bu sınıf, "Sürekli Entegrasyon" dizesini tutacak bir ad değişkenine sahip olacaktır. Bu dizi web sayfasında görüntülenecektir. Basit Proje'ye sağ tıklayın ve menü seçeneğini seçinAdd → Class.

Step 2 - Sınıfa bir ad verin Tutorial.cs ve ekranın altındaki Ekle düğmesini tıklayın.

Step 3- Tutorial.cs dosyasını açın ve içine aşağıdaki kodu ekleyin. Bu kod sadece adında bir dize oluştururNameve Oluşturucu'da adı bir dize değerine atayın Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Step 4 - Değişikliği yapalım Demo.aspx.csBu yeni sınıfı kullanmak için dosya. Bu dosyadaki kodu aşağıdaki kodla güncelleyin. Dolayısıyla bu kod şimdi yukarıda oluşturulan sınıfın yeni bir örneğini oluşturacaktır.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Step 5 - Bizim demo.aspx dosya, şimdi referans verelim tp.Name değişken, içinde oluşturulan aspx.cs dosya.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

Kodumuzun bu değişikliklerle sorunsuz çalıştığından emin olmak için kodu Visual Studio'da çalıştırabilirsiniz. Derleme tamamlandığında aşağıdaki çıktıyı almalısınız.

Step 6- Şimdi Unit testlerimizi projeye ekleme zamanı. Sağ tıklayınSolution ve menü seçeneğini seçin Add → New Project.

Step 7 - Şuraya git Test ve sağ tarafta, seçin Unit Test Project. Olarak bir isim verinDemoTest ve ardından Tamam'ı tıklayın.

Step 8 - senin içinde Demo Test project, Basit projeye ve gerekli olana bir referans eklemeniz gerekir testing assemblies. Projeye sağ tıklayın ve menü seçeneğini seçinAdd Reference.

Step 9 - Açılan sonraki ekranda Projeler'e gidin, seçin Simple Reference ve Tamam'ı tıklayın.

Step 10 - Tıklayın Add Reference tekrar, Montajlara gidin ve yazın WebArama kutusunda. Sonra bir referans ekleyinSystem.Web.

Step 11 - içinde Unit Test file, aşağıdaki kodu ekleyin. Bu kod, Tutorial sınıfının bir dize adı değişkenine sahip olmasını sağlayacaktır. Ayrıca, Adın "Sürekli Entegrasyon" değerine eşit olması gerektiği gerçeğini de ortaya koyacaktır. Bu bizim basit Test durumumuz olacak.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Step 12- Şimdi çalıştığından emin olmak için testimizi Visual Studio'da çalıştıralım. Visual Studio'da menü seçeneğini seçinTest → Run → All Tests.

Testi çalıştırdıktan sonra, Visual Studio'nun sol tarafında Testin başarıyla çalıştırıldığını göreceksiniz.

TeamCity'de Sürekli Testi Etkinleştirme - Artık tüm test durumları yerinde olduğuna göre, bunları Team City sunucumuza entegre etme zamanı.

Step 13- Bunun için Proje konfigürasyonumuzda bir inşa adımı oluşturmamız gerekiyor. Proje ana sayfanıza gidin ve Yapılandırma Ayarlarını Düzenle'yi tıklayın.

step 14 - Ardından, Build Step → MS Build seçeneğine gidin ve aşağıdaki ekran görüntüsünde gösterildiği gibi Add build step seçeneğini tıklayın.

Açılan sonraki ekranda aşağıdaki değerleri ekleyin -

• Çalıştırıcı türünü Visual Studio Testleri olarak seçin.

• İsteğe bağlı bir Test adımı adı girin.

• Test Motoru türünü şu şekilde seçin: VSTest.

• Test Motoru sürümünü şu şekilde seçin: VSTest2013.

• Test dosyaları adında konumu şu şekilde girin: DemoTest\bin\Debug\DemoTest.dll - Bunu hatırla DemoTestBirim Testlerimizi içeren projemizin adıdır. DemoTest.dll ilk derleme adımımız tarafından oluşturulacaktır.

• Ekranın sonunda görünecek olan Kaydet'i tıklayın.

Şimdi projeniz için 2 inşa adımınız olacak. İlki, uygulama kodunuzu ve test projenizi oluşturacak olan Oluşturma adımıdır. Ve sonraki, test durumlarınızı çalıştırmak için kullanılacaktır.

Step 15- Artık tüm kodunuzu Git'te kontrol etme zamanı, böylece tüm oluşturma süreci tetiklenebilir. Bu sefer tek fark,git add ve git commit gelen komut Demo parent folder aşağıdaki ekran görüntüsünde gösterildiği gibi.

Şimdi yapı tetiklendiğinde, testin geçtiğini söyleyen bir ilk çıktı göreceksiniz.

Step 16 - Test geçti sonucuna tıklarsanız ve Test sekmesine giderseniz, şimdi UnitTest1'in yürütüldüğünü ve geçtiğini göreceksiniz.

Sürekli İnceleme, gerçek testler çalıştırılmadan önce kodunuz için yapılan denetimin otomatik kod incelemesi sürecidir. Yazılımı incelemek ve test etmek arasında ince farklar vardır. Test dinamiktir ve işlevselliği test etmek için yazılımı çalıştırır. İnceleme, kodu önceden tanımlanmış bir dizi kurala göre analiz eder.

Denetçiler (veya statik ve dinamik analiz araçları), ekiplerin uyması gereken tanımlanmış standartlar (genellikle kodlama veya tasarım ölçütleri) tarafından yönlendirilir. Denetim hedeflerinin örnekleri arasında kodlama “gramer” standartları, mimari katman uyumu, kod tekrarlama ve diğerleri yer alır.

Sürekli İnceleme, bir keşif ile düzeltme arasındaki süreyi azaltır. Çok sayıda Sürekli İnceleme aracı mevcuttur. Bu örnek için, kullanacağızNCover 3.xTeamCity ile entegrasyona sahiptir. Sürekli Denetimi nasıl yapabileceğimize ve bizim için neler yapabileceğine bakalım.

NCover'ı İndirin ve Yükleyin

NCover, indirilmesi ve kurulması gereken ayrı bir üründür. NCover'ı İndirmek için, lütfen aşağıdaki bağlantıya tıklayın ve 32 bit yükleyiciyi indirin -http://www.ncover.com/info/download.

İndirilen yükleyiciyi çalıştırın ve ardından yükleyici başladıktan sonra İleri'ye tıklayın.

Lisans sözleşmesini kabul edin ve ardından İleri'ye tıklayın.

Varsayılan bileşenleri kabul edin ve İleri'ye tıklayın.

Kuruluma başlamak için Kur düğmesine tıklayın.

Kurulumu tamamlamak için Finish butonuna tıklayın.

NCover kurulumunu ilk kez şuraya giderek başlatın: C:\Program Files (x86)\NCover\ NCover.Explorer.exe. Sadece ilk kez bir deneme anahtarı kurmanız gerekecek, bu basit bir süreçtir.

TeamCity'de Projeyi NCover Kullanacak Şekilde Yapılandırın

Step 1 - Proje ana ekranınıza gidin ve Yapılandırma Ayarlarını Düzenle'yi tıklayın.

Step 2 - Build Steps'e gidin ve TestStep. Sürekli Muayene, tanımlanan Birim testleri ile birlikte yürütülmelidir.

Step 3 - .Net Kapsama bölümünde, .Net Coverage Tool. Ve sonra aşağıdaki ayarları seçin.

• NCover (3.x) olarak .Net Kapsama aracını seçin
• X86 olarak platform
• V4.0 versiyonu
• NCover yolu C: \ Program Files (x86) \ NCover olarak
• Diğer ayarları olduğu gibi bırakın

Step 4 - Kaydet'i tıklayın.

Step 5 - Şimdi projenizin ana ekranına gidin ve Çalıştır'a tıklayın.

Step 6- Yapı çalıştırıldıktan sonra Test geçti'ye tıklayın. Şimdi bir Kod Kapsamı ekranı göreceksiniz ve birçok metrik göstergesi göreceksiniz.

Step 7 - Artık Kod Analizi hakkında daha fazla bilgi almak için Kod Kapsamı sekmesine tıklayabilirsiniz.

Step 8 - tıklayın fullcoveragereport.html. Şimdi, için yapılan denetim hakkında tam kapsamlı bir rapor alacaksınız..Net code.

Sürekli Veritabanı Entegrasyonu, bir projenin sürüm kontrol havuzuna herhangi bir değişiklik uygulandığında veritabanınızı yeniden oluşturma ve verileri test etme işlemidir.

Veritabanı Entegrasyonunda, genellikle veritabanı entegrasyonuyla ilgili tüm yapılar -

• Bir sürüm kontrol sisteminde bulunmalıdır.
• Sertlik açısından test edilebilir ve politikaya uygunluk açısından incelenebilir.
• Derleme komut dosyalarınız kullanılarak oluşturulabilir.

Sürekli Veritabanı Entegrasyonuna dahil edilebilecek faaliyetler aşağıdakilerden herhangi biri olabilir -

Drop a Database - Veritabanını bırakın ve ilişkili verileri kaldırın, böylece aynı ada sahip yeni bir veritabanı oluşturabilirsiniz

Create a new Database - Veri Tanımlama Dili (DDL) kullanarak yeni bir veritabanı oluşturun.

Insert the Initial Data - Sisteminizin teslim edildiğinde içermesi beklenen ilk verileri (ör. Arama tabloları) ekleyin.

Migrate Database and Data - Veritabanı şemasını ve verileri periyodik olarak taşıyın (mevcut bir veritabanına dayalı bir sistem oluşturuyorsanız).

Modify Column Attributes - Gereksinimlere ve yeniden düzenlemeye göre tablo sütun özelliklerini ve kısıtlamalarını değiştirin.

Modify Test Data - Test verilerini birden çok ortam için gerektiği gibi değiştirin.

Dolayısıyla, Sürekli Veritabanı örneğimizde, aşağıdaki adımları uygulayacağız -

• Bir MS SQL Server veritabanı ve ilgili bir tablo oluşturacağız.

• SQL Server Management Studio'dan bir script oluşturacağız. Bu veritabanı komut dosyası, veritabanımızda tablomuzu kurmak için kullanılacaktır.

• Bu veritabanına erişmek için ASP.Net projemizde bir kod yazacağız.

• Bu betiği çalıştırmak için TeamCity'de projemizde bir adım oluşturacağız.

• Komut dosyamızı Git'e kontrol edeceğiz.

Daha önceki bir bölümde oluşturulan AWS veritabanında bunu yapma adımları.

Step 1- Bir MS SQL Server veritabanı ve ilgili bir tablo oluşturun. SQL Server Management Studio'yu açalım ve basit bir veritabanı ve tablo oluşturalım. Veritabanlarına sağ tıklayın ve tıklayınNew Database.

Step 2 - olarak adlandır Demodb ve Tamam'ı tıklayın

Step 3 - Yeni veritabanında, sağ tıklayın ve yeni bir tablo oluşturun.

Step 4 - Tabloya istediğiniz sütunları ekleyebilirsiniz.

Step 5 - Tabloyu kaydedin ve olarak adlandırın Demotb.

Step 6 - Şimdi masaya sağ tıklayın ve menü seçeneğini seçin Script Table as → Drop and Create to → File.

Step 7 - Dosyayı demo proje klasörüne kaydedin. Sample.sql.

Veritabanı komut dosyasının nasıl görüneceği budur. Varsa önce mevcut bir tabloyu bırakır ve ardından tabloyu yeniden oluşturur.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8 - Şimdi hızlıca değiştirelim ASP.Net code yeni veritabanına başvurmak için.

Step 9 - içinde Tutorial.cs dosyanda Demo project, aşağıdaki kod satırlarını ekleyin. Bu kod satırları veritabanınıza bağlanacak, Sunucu sürümünü alacak ve sürüm adını Ad değişkeninde saklayacaktır. Bu isim değişkeniniDemo.aspx.cs aracılığıyla dosya Response.write komut.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Step 10 - Aşağıdaki kodu Demo.aspx.cs SQL Server sürümünü görüntülediğinden emin olmak için.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

Şimdi kodu çalıştırırsak, tarayıcıda aşağıdaki çıktıyı alacaksınız.

Step 11- Şimdi veritabanı betiğini çağıracak olan TeamCity adımımızı ekleyelim. Proje panonuza gidin ve tıklayınEdit Configuration Settings.

Step 12 - Adımları Oluştur'a gidin ve tıklayın Add build step.

Aşağıdaki seçenekleri seçin (MS SQL Server istemcisinin CI Sunucusuna yüklenmesi gerektiğini unutmayın).

• Koşucu türü Komut Satırı olmalıdır.

• İsteğe bağlı bir Adım Adı verin.

• Çalıştırma parametreleri ile yürütülebilir olmalıdır.

• Komut çalıştırılabilir olmalıdır C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe

• Komut parametreleri olmalıdır -S WIN-50GP30FGO75 -i Sample.sql. Burada –S, SQL Server örneğinin adını verir.

Step 13 - Kaydet'i tıklayın.

Şimdi sağlanması gereken şey inşa düzenidir. Yapım sırasının aşağıdaki gibi olduğundan emin olmalısınız.

Step 14 - Derleme adımlarını yeniden sıralama seçeneğini belirleyerek yapı sırasını değiştirebilirsiniz.

• Veritabanı kurulumu ilk olmalıdır - Bu, veritabanınızı yeniden oluşturmak için kullanılacaktır.

• Sırada uygulamanızın yapısı var.

• Sonunda test kurulumunuz.

Step 15 - Şimdi çalıştırın git add ve git commit komut böylece Sample.sqldosya Git'e kontrol edilir. Bu, bir yapıyı otomatik olarak tetikleyecektir. Ve bu yapı geçmeli.

Artık döngünüzde olduğu gibi sürekli bir veritabanı entegrasyonu yönüyle tam teşekküllü bir derleme döngüsüne sahipsiniz. Bir sonraki bölümde, bunu daha ileri götürelim ve Sürekli Dağıtıma bakalım.

Artık bunu yerel bir SQL Sunucusu ile yaptığınıza göre, aynı adımları bir AWS MS SQLÖnceki bölümlerden birinde oluşturulan sunucu. Bir Microsoft SQL Sunucusuna bağlanmak için, aşağıdaki kural ile bağlanmanız gerekir.

Step 16- Öncelikle AWS'de veritabanı örneğinize atanan adın ne olduğunu görün. AWS'de oturum açtığınızda, veritabanı bölümünün altındaki RDS bölümüne gidin.

Step 17 - Açılan sonraki ekranda Veritabanı Eşgörünümlerine tıklayın.

step 18- Veritabanınıza tıklayın ve uç noktayı not edin. Aşağıdaki ekran görüntüsünde,demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Step 19 - Şimdi veritabanına bağlanmak için SQL Server Management Studio, bağlantıyı şu şekilde belirtmeniz gerekir: demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Örnek adı ve bağlantı noktası no arasında kullanılan virgüllere dikkat edin).

Aşağıdaki ekran görüntüsü, veritabanına başarılı bir bağlantıyı göstermektedir.

Sonra aynı adımları tekrarlayabilirsiniz. Sqlcmd command aşağıdaki gibi olacak -

Aynı komut, TeamCity'deki Veritabanı oluşturma adımında değiştirilebilir. Çalıştırdığınızdasqlcmd commandtablo, AWS'deki SQL Server veritabanınızda otomatik olarak oluşturulacaktır.

Otomatik derlemeler ve tekrarlanabilir derlemeler. Otomatik testler ve tekrarlanabilir testler. Test kategorileri ve test sıklıkları. Sürekli denetimler. Sürekli veritabanı entegrasyonu. Etkili bir CI ortamı oluşturmadaki bu görevler dizisi, öncelikle bir temel faydayı sağlar: çalışan yazılımı herhangi bir zamanda, herhangi bir ortamda yayınlamak.

Önceki bölümlerimizde, aşağıdaki bölümlerin tümünü gerçekleştirdik -

• Kodumuzu oluşturduk.
• TeamCity'de düzgün bir yapı sağlandı.
• Bir Veritabanı Entegrasyon süreci oluşturdu.
• Başarılı testler gerçekleştirdi.

Şimdi geriye kalan tek şey, tüm sürecimizin tamamlanması için otomatik bir dağıtım gerçekleştirmek.

Bizim durumumuzda otomatik bir dağıtım için şu adımları izlememiz gerekiyor -

• Dağıtım sunucumuzda, IIS'nin kurulu olduğundan emin olun.

• IIS kullanıcısına veritabanımıza erişim verildiğinden emin olun.

• Siteyi kurulduğunda yayınlamak için kullanılacak bir yayınlama profili oluşturun.

• Otomatik dağıtım yapmak için MSBuild komutumuzu değiştirdiğimizden emin olun.

• Otomatik yayınlama yapmak için TeamCity'yi otomatikleştirin.

• Yap git commit tüm dosyalarınızın Git'te olmasını sağlamak için.

Step 1- Yerel bir IIS Sunucusu yapılandırın. Yerel veya uzak bir IIS Sunucunuz varsa, uygulamamızı dağıtmak için aşağıdaki yapılandırma gerçekleştirilebilir. Bir dağıtımın otomatik bir şekilde yapılmadan önce manuel olarak yapılıp yapılamayacağını görmek her zaman iyi bir uygulamadır.

Step 2 - Bir Windows 2012 sunucusunda, Sunucu Yöneticinize gidin ve Rolleri ve Özellikleri Ekle'yi tıklayın.

Step 3 - Açılan sonraki ekranda İleri'yi tıklayın.

Step 4 - Sonraki ekranda rol tabanlı veya özellik tabanlı kurulumu seçin ve İleri'yi tıklayın.

Step 5 - Varsayılan sunucuyu seçin ve İleri'yi tıklayın.

Step 6 - Web sunucusu rolünü seçin ve İleri'yi tıklayın.

Step 7 - Açılan sonraki ekranda İleri'yi tıklayın.

Step 8 - Görünen sonraki ekranda tekrar İleri'yi tıklayın.

Step 9 - Açılan sonraki ekranda İleri'yi tıklayın.

Step 10 - Son ekranda, IIS'yi yüklemek için Yükle düğmesine tıklayabilirsiniz.

IIS'yi kurduktan sonra, Internet Information Services'i açarak açabilirsiniz.

Step 11 - Uygulama Havuzları'na tıklayın, adında bir havuz göreceksiniz. DefaultAppPool. Bunun sonraki adımda SQL Server'a erişimi olması gerekir.

Step 12 - Bir ASP.Net uygulamasını bir MS SQL Server uygulamasına bağlamamız gerekirse, varsayılan uygulama havuzuna SQL Server örneğine erişim vermeliyiz, böylece bizim Demodb veri tabanı.

Step 13- SQL Server Management Studio'yu açın. Girişler'e gidin, sağ tıklayın ve menü seçeneğini seçinNew Login.

Sonraki ekranda, aşağıdaki parametreleri güncelleyin ve Tamam'a tıklayın.

• IIS APPPOOL \ DefaultAppPool olarak oturum açma adı.
• Varsayılan veritabanı - Bu, demodb olan veritabanımız olmalıdır.

Step 14 - Bir Publish Profile. Yayınlama profili, Visual Studio'da daha sonra MS Build ile ve buna göre herhangi bir CI Sunucusunda kullanılabilen bir dağıtım paketi oluşturmak için kullanılır. Bunu yapmak için, Visual Studio'dan projeye sağ tıklayın ve Yayınla menü seçeneğine tıklayın.

Step 15 - Açılan bir sonraki ekranda, yeni bir Yayınlama profili oluşturmayı seçin, bir isim verin - DemoDeployment. Ardından İleri düğmesine tıklayın.

Görünen sonraki ekranda aşağıdaki değerleri ekleyin -

• Yayınlama yöntemini Web Dağıtımı olarak seçin.
• Sunucuyu localhost olarak girin.
• Site adını Varsayılan Web Sitesi / Demo olarak girin.
• Hedef URL'yi şöyle koyun http://localhost/Demo

Ardından İleri düğmesine tıklayın.

Step 16 - Sonraki ekranda İleri'yi tıklayın.

Step 17 - Açılan son ekranda Yayınla düğmesini tıklayın.

Şimdi gidersen C:\Demo\Simple\Properties\PublishProfiles projenizin konumu, yeni bir publish profile xml fileoluşturuldu. Bu yayınlama profili dosyası, uygulamanızı yerel IIS sunucusunda yayınlamak için gereken tüm ayrıntılara sahip olacaktır.

Step 18- Şimdi MSBuild komutumuzu özelleştirip yukarıdaki yayınlama profilini kullanalım ve ne olacağını görelim. MSBuild komutumuzda aşağıdaki parametreleri belirtiyoruz -

• Derlemede Dağıtma doğrudur - bu, başarılı bir derleme tamamlandığında otomatik dağıtımı tetikleyecektir.

• Ardından, yukarıdaki adımda kullanılan Yayınlama profilini kullanmaktan söz ediyoruz.

• Visual Studio sürümü, kullanılan Visual Studio sürümünün ne olduğuna ilişkin MSBuild dağıtım özelliğinden söz edilecektir.

Yukarıdaki komutu çalıştırdığınızda, MSBuild bir derleme ve dağıtım sürecini tetikler. Dikkat edeceğiniz şey, onu bizimDefault Website IIS Sunucumuzda.

Şimdi siteye göz atarsak - http://localhost/Demo/Demo.aspx Aşağıdaki çıktıyı göreceğiz, bu da MSBuild'in web sitemize başarılı bir dağıtım yaptığı anlamına gelir.

Step 19 - TeamCity aracılığıyla otomatikleştirme - Şimdi, yukarıda belirtilen adımlara dayalı olarak uygulamamızı dağıtmak için MSBuild'i otomatik olarak kullanmak için TeamCity sunucumuza bir görev ekleme zamanı.

Step 20 - Proje panonuza gidin ve tıklayın Edit Configuration Settings.

Step 21 - Build Steps'e gidin ve Add a Build steps'i tıklayın.

Aşağıdaki seçenekleri seçin -

• Koşucu türü MSBuild olmalıdır

• İsteğe bağlı bir Adım adı verin

• Derleme yolunu Simple / Simple.csproj olarak girin

• MSBuild sürümünü Microsoft Derleme Araçları 2013 olarak tutun

• MSBuild Toolsversion'ı 12.0 olarak tutun

• Komut satırını / p olarak koyun: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0

Step 22 - Kaydet'i tıklayın.

Derleme adımlarında, Dağıtma adımının zincirdeki son adım olduğundan emin olun.

Step 23 - Şimdi bir final yapalım git commit, tüm dosyaların Git'te olduğundan ve TeamCity tarafından kullanılabileceğinden emin olmak için.

Tebrikler, uygulamanız için herhangi bir zamanda çalıştırılabilen eksiksiz bir Sürekli Entegrasyon Döngüsü oluşturdunuz.

Şimdiye kadar öğrendiğimiz tüm derslere dayanarak, Sürekli Entegrasyonun en iyi uygulamalarının son bir incelemesini yapalım -

• Maintain a code repository- Bu en temel adımdır. Tüm örneklerimizde, kod tabanından Yayınlama profillerine, veritabanı betiklerine kadar her şey bir Git deposunda tutulur. Her şeyin kod havuzunda tutulması her zaman sağlanmalıdır.

• Automate the build- Bir derlemeyi otomatikleştirmek ve bir yayınlama profili kullanmak için MSBuild'i nasıl kullanacağımızı gördük. Bu, yine sürekli Entegrasyon sürecinde önemli bir adımdır.

• Make the build self-testing - Birim test durumlarını yerinde tutarak yapıyı test edebileceğinizden emin olun ve bu test senaryoları Sürekli Entegrasyon sunucusu tarafından çalıştırılabilecek şekilde olmalıdır.

• Everyone commits to the baseline every day- Bu, Sürekli Entegrasyonun temel ilkesidir. Yapıyı kimin kırdığını görmek için tüm sürecin sonuna kadar kalmanın bir anlamı yok.

• Every commit (to baseline) should be built- Uygulamaya yapılan her taahhüdün başarıyla oluşturulması gerekir. Yapı herhangi bir nedenle başarısız olursa, yapının başarılı olmasını sağlamak için kodun değiştirilmesi gerekir.

• Keep the build fast- Derleme yavaşsa, Sürekli Entegrasyon sürecinin tamamında bir sorun olduğunu gösterir. Derlemelerin her zaman bir süre ile sınırlı olduğundan emin olun, tercihen asla 10 dakikanın ötesine geçmemelidir.

• Everyone can see the results of the latest build- TeamCity kontrol paneli herkese başarılı veya başarısız olan tüm yapıların bir görünümünü verir. Bu, Sürekli Entegrasyon sürecine dahil olan tüm insanlara iyi bir fikir verir.