Sürekli Entegrasyon (CI) nedir ve nasıl faydalıdır? [kapalı]

Bazıları Bana Sürekli Entegrasyon kavramını, nasıl anlaşılır bir şekilde çalıştığını açıklayabilir mi? Ve bir şirket neden kod dağıtım iş akışında CI kullanmalı? Ben bir geliştiriciyim ve şirketim (çoğunlukla yapım ekibi) Team City kullanıyor. Bir geliştirici olarak, SVN'ye her zaman ödeme yapar, günceller ve taahhüt ederim, ancak TeamCity veya CI hakkında hiçbir zaman gerçekten uğraşmak zorunda kalmadım. Bu yüzden CI'nin faydasının ne olduğunu anlamak istiyorum? CI Agile yöntemlerinin bir parçası mı?

Özetle Sürekli Entegrasyon, çalışmanızı kaydettiğiniz, belge yönetim sistemine (sizin durumunuzda SVN) ittiğiniz, tüm testlerin otomatik olarak yürütüldüğü (hem birim, entegrasyon, fonksiyonel vb. Testler) hem de uygulamanın derlendiği ve hazırlandığı anlamına gelir teslimat için (yani ISO görüntüsü oluşturulur). Sürekli Entegrasyon, Sürekli Teslim ile aynı değildir. Teslimat hala farklı anlarda yapılır. CI, gerektiğinde ürünün teslim edilebilmesini sağlar , başka bir şey yok.

Ne zaman bir şeyler ters giderse, takım bir bildirim alır. Genellikle bu noktada tüm çalışmalar durdurulur ve tüm çabalar ürünün istikrarlı bir şekilde olduğundan emin olmak için yoğunlaşır. Sistem yeşil değilken depoda hiçbir itme ve işlem gerçekleşmez.

CI, ürünün her zaman kararlı bir durumda olmasını ve potansiyel olarak her zaman teslim edilebilmesini sağlar. Lütfen ahırın özelliklerin tamamlandığı anlamına gelmediğini unutmayın. Yarı uygulanan özellikler de olabilir, ancak sistem kararlı olabilir.

CI genellikle Agile metodolojileri ile ilişkilidir, ancak kişisel olarak CI'nin kesin tarihini bilmiyorum.

Sürekli entegrasyon şu anlama gelir: kodun gerçekten çalışan ve test edilebilen bir ürüne entegre edilmesi (daha önce olduğu gibi) geliştirme yaşam döngüsünün sonlarında ayrı bir aktivite olarak değil, her zaman gerçekleşir .

Uygulamanın oluşturma işleminin tamamen otomatik olmasını ve otomatikleştirilmiş bir test paketini ve kodun geçerli durumunu oluşturan ve üzerinde test paketini çalıştıran bir sunucu gerektirir. Bu, günlük olarak veya her kod kontrolünden sonra bile gerçekleşmelidir.

Avantajı, derleme hatalarına neden olan kod değişiklikleri hakkında derhal geri bildirim olmasıdır (örneğin, geliştirici tüm değişiklikleri kontrol edemediğinden veya derleme sisteminde bulunmayan bazı bileşenleri kullandığından) veya test durumu hataları. Hangi değişikliklere neden olduğunu ve sorumlu kişinin hala yaptıklarıyla ilgili yeni anıları olduğunu bildiğiniz için, bu tür hataların düzeltilmesi çok daha kolay hale gelir.

CI olmadan, tüm bu hatalar entegrasyon aşamasında aynı anda birlikte ortaya çıkar ve bu da düzeltilmelerini son derece zorlaştırır.

Gelişimde belirli bir stiliniz olabilir : Ödeme, kodlama, derleme, kontrol etme, lanetleme, değiştirme, derleme, tezahürat, taahhüt. Çalışma kodunu, belki de iş gününüzün sonunda veya bir özellik tamamlandığında olduğu gibi, daha az ayrıntılı bir şekilde işlersiniz. API kitaplıklarını her içe aktardığınızda bağımlılıklarınızı doğrularsınız.

Başkalarıyla birlikte kodlamaya başladığınızda ve karşılıklı bağımlılıklar olduğunda sürekli entegrasyonu benimsemek mantıklıdır. Bunun nedeni, kodunuza bağlı olan kişilerdeki değişikliklerin etkisini bilememeniz ve içe aktarmalarınızı her güncellemeniz gerektiğinde sinyal almamanızdır.

Bu nedenle, ikinizden biri bir değişiklik yaptığınızda, her iki proje birlikte oluşturulmalı ve test edilmelidir, yani birbirinizin API'sine karşı çalıştırılmalıdır, yeni kütüphane ile oluşturulmuş ve test edilmiştir.

Neden sürekli? Çünkü her iki kod tabanında bir değişiklik olduğunda temiz bir yapıyı test eden bir sistemle entegrasyonun koordinasyonunu temsil etmek, tüm bunları bir insan için organize etmekten daha kolaydır. Sistem ölçeklendirilebilir.

Sürekli entegrasyonun iki yönü vardır.

1. Geliştiricilerin devam eden çalışmalarını sürekli olarak diğer geliştiricilerin kararlı kodlarıyla bütünleştirebilmelerini sağlayan geliştirme kaynağı kontrol stratejisi.
2. Kaynak kontrolü taahhüdü tarafından tetiklenen kaynak kodunun otomatik oluşturulması ve test edilmesi

Nokta 1 kritiktir. Geliştiricilerin gerçekte sık ve küçük olmak üzere gerçekleştirdikleri birleştirmeleri, birleştirmelerin başarılı olma olasılığını daha da arttıran bir harekettir.

Nokta 2, mevcut kodun kırılmasıyla başarısız olan birleştirmeleri hızlı bir şekilde tanımlayarak, nokta 1'in güvenli bir şekilde gerçekleşmesini sağlamak için gereken araçlar ve çerçevedir.

Ne kadar yararlı?

İnanılmaz şekilde. Bir proje üzerinde çalışan bir geliştirici olarak, zamanınızın çoğunu yaptığınız işe odaklanarak geçirmenize ve ekibin geri kalanından eşzamanlı çalışma konusunda endişelenmenize izin vermez. Mevcut işiniz tamamlandığında, değişikliklerinizi ekibin geri kalanında yayınlarsınız ve sonraki birkaç saat içinde değişiklikleriniz mevcut işleriyle birleştirilir.

Onsuz, geliştiriciler büyük patlama birleştirmeleri yapıyorlar. Genellikle çalışmalarının birkaç gününü almak ve ekibin geri kalanının tek seferde yaptığı tüm değişikliklerle birleştirmek zorunda kalırsınız. Bir birleştirme fark edilir derecede kötüleştiğinde, diğer geliştirici muhtemelen diğer çalışmalara geçecek ve birleştirme karmaşasını çözmek için ince ayrıntıları unutmaya başlayacak. Daha da kötüsü, sürekli derleme ve test olmadan, kod derlendiği sürece, birleştirme hataları kodda görünebilir ve test (veya müşteriler) bunları bulana kadar alınmayacaktır.

CI, aşağıdakilere sahip olduğunuzda yararlıdır:

• Kod derleme
• Gerçek test seti
• Kaynak kodunuzu temel alan raporlar (kod kapsamı, kod standartlarının şiddeti, vb.)
• Kod başarıyla derlendikten sonra periyodik olarak yaptığınız rutin

Liste devam edebilir ..