Kod Olarak Altyapı: XP kullanarak sorunların üstesinden nasıl gelinir

Merhaba Habr! Daha önce kod paradigması olarak Altyapıdaki yaşamdan şikayetçiydim ve mevcut durumu çözecek hiçbir şey teklif etmedim. Bugün size hangi yaklaşımların ve uygulamaların umutsuzluk uçurumundan kaçmanıza ve durumu doğru yöne yönlendirmenize yardımcı olacağını anlatmak için geri döndüm.

Bir önceki yazıda "Kod olarak altyapı: ilk tanışma" Bu alana ilişkin izlenimlerimi paylaştım, bu alandaki mevcut durumu yansıtmaya çalıştım ve hatta tüm geliştiricilerin bildiği standart uygulamaların yardımcı olabileceğini önerdim. Hayata dair pek çok şikayet varmış gibi görünebilir, ancak mevcut durumdan çıkışa yönelik herhangi bir öneri yoktu.

Biz kimiz, neredeyiz ve ne gibi sorunlarımız var?

Şu anda altı programcı ve üç altyapı mühendisinden oluşan Sre Onboarding Takımındayız. Hepimiz Altyapıyı kod (IaC) olarak yazmaya çalışıyoruz. Bunu yapıyoruz çünkü temel olarak nasıl kod yazılacağını biliyoruz ve "ortalamanın üzerinde" geliştiriciler olma geçmişimiz var.

• Bir dizi avantajımız var: belirli bir altyapı, uygulama bilgisi, kod yazma yeteneği, yeni şeyler öğrenme arzusu.
• Bir de eksiği olan sarkık bir kısım var: Altyapı donanımları konusunda bilgi eksikliği.

IaC'mizde kullandığımız teknoloji yığını.

• Kaynak oluşturmak için Terraform.
• Görüntüleri birleştirmek için paketleyici. Bunlar Windows, CentOS 7 görüntüleridir.
• Jsonnet, drone.io'da güçlü bir yapı oluşturmanın yanı sıra packer json ve terraform modüllerimizi oluşturmak için.
• Azure.
• Görüntüleri hazırlarken Ansible.
• Yardımcı hizmetler ve komut dosyalarının hazırlanması için Python.
• Ve tüm bunlar, ekip üyeleri arasında paylaşılan eklentilerle VSCode'da.

Benim sonucum son makale Şöyle oldu: Ben (öncelikle kendime) iyimserlik aşılamaya çalıştım, bu alanda var olan zorluklar ve karmaşıklıklarla başa çıkmak için bildiğimiz yaklaşımları ve uygulamaları deneyeceğimizi söylemek istedim.

Şu anda aşağıdaki IaC sorunlarıyla mücadele ediyoruz:

• Kod geliştirme araçlarının ve araçlarının kusurlu olması.
• Yavaş dağıtım. Altyapı gerçek dünyanın bir parçasıdır ve yavaş olabilir.
• Yaklaşım ve uygulamaların eksikliği.
• Yeniyiz ve pek bir şey bilmiyoruz.

Ekstrem Programlama (XP) imdada yetişiyor

Tüm geliştiriciler Ekstrem Programlamaya (XP) ve onun arkasında yatan uygulamalara aşinadır. Birçoğumuz bu yaklaşımla çalıştık ve başarılı olduk. Öyleyse neden altyapı zorluklarının üstesinden gelmek için burada belirtilen ilke ve uygulamaları kullanmıyorsunuz? Bu yaklaşımı benimsemeye ve ne olacağını görmeye karar verdik.

XP yaklaşımının sektörünüze uygulanabilirliğinin kontrol edilmesiXP'nin çok uygun olduğu ortamın ve bizimle ilişkisinin bir açıklaması:

1. Dinamik olarak değişen yazılım gereksinimleri. Nihai hedefin ne olduğu bizim için açıktı. Ancak ayrıntılar değişebilir. Nereye taksi yapmamız gerektiğine kendimiz karar veriyoruz, dolayısıyla gereksinimler periyodik olarak değişiyor (çoğunlukla kendimiz). Otomasyonu kendisi yapan ve gereksinimleri ve iş kapsamını kendisi sınırlayan SRE ekibini ele alırsak, bu nokta çok iyi uyuyor.

2. Yeni teknoloji kullanan sabit süreli projelerin neden olduğu riskler. Bilmediğimiz bazı şeyleri kullanırken risklerle karşılaşabiliriz. Ve bu %100 bizim durumumuzdur. Projemizin tamamı, tam olarak aşina olmadığımız teknolojilerin kullanılmasından oluşuyordu. Genel olarak bu sürekli bir sorundur, çünkü... Altyapı sektöründe sürekli olarak birçok yeni teknoloji ortaya çıkıyor.

3,4. Küçük, aynı yerde bulunan genişletilmiş geliştirme ekibi. Kullandığınız otomatik teknoloji, birim ve fonksiyonel testlere olanak tanır. Bu iki nokta bize pek uymuyor. Birincisi koordineli bir ekip değiliz, ikincisi dokuz kişiyiz ve büyük bir ekip sayabiliriz. Her ne kadar bazı “büyük” ekip tanımlarına göre çoğu 14+ kişiden oluşuyor.

Bazı XP uygulamalarına ve bunların geri bildirimin hızını ve kalitesini nasıl etkilediğine bakalım.

XP Geri Bildirim Döngüsü Prensibi

Benim anlayışıma göre geri bildirim şu sorunun cevabıdır: Doğru şeyi mi yapıyorum, oraya mı gidiyoruz? XP'nin bunun için ilahi bir planı var: bir zaman geri bildirim döngüsü. İlginç olan şu ki, ne kadar düşük olursak işletim sisteminin gerekli soruları yanıtlamasını o kadar hızlı sağlayabiliriz.

Bu, BT sektörümüzde hızlı bir şekilde bir işletim sistemi edinmenin mümkün olduğu oldukça ilginç bir tartışma konusudur. Bir projeyi altı ay boyunca yapmanın ne kadar acı verici olduğunu hayal edin ve ancak o zaman başlangıçta bir hata olduğunu anlayın. Bu, tasarımda ve karmaşık sistemlerin herhangi bir yapımında gerçekleşir.

IaC durumumuzda geri bildirim bize yardımcı olur. Hemen yukarıdaki şemada küçük bir düzenleme yapacağım: Yayın planının aylık bir döngüsü yok, günde birkaç kez gerçekleşiyor. Bu işletim sistemi döngüsüne bağlı, daha ayrıntılı olarak inceleyeceğimiz bazı uygulamalar var.

Önemli: Geri bildirim yukarıda belirtilen tüm sorunlara çözüm olabilir. XP uygulamalarıyla birleştiğinde sizi umutsuzluğun uçurumundan çıkarabilir.

Kendinizi umutsuzluk uçurumundan nasıl kurtarırsınız: üç uygulama

Testler

XP geri bildirim döngüsünde testlerden iki kez bahsedilir. Bu sadece böyle değil. Tüm Ekstrem Programlama tekniği için son derece önemlidirler.

Birim ve Kabul testlerinizin olduğu varsayılmaktadır. Bazıları size birkaç dakika içinde, bazıları ise birkaç gün içinde geri bildirim verir, bu nedenle yazılmaları daha uzun sürer ve daha az gözden geçirilirler.

Daha fazla test yapılması gerektiğini gösteren klasik bir test piramidi var.

Bu çerçeve bir IaC projesinde bizim için nasıl geçerlidir? Aslında... hiç de değil.

• Birim testleri, çok sayıda olması gerektiği gerçeğine rağmen çok fazla olamaz. Veya çok dolaylı olarak bir şeyi test ediyorlar. Aslında bunları hiç yazmıyoruz diyebiliriz. Ancak bu tür testler için yapabildiğimiz birkaç uygulamayı burada bulabilirsiniz:
  1. Jsonnet kodunu test etme. Bu, örneğin oldukça karmaşık olan drone montaj hattımızdır. Jsonnet kodu testlerle iyi bir şekilde ele alınmıştır.
     Bunu kullanıyoruz Jsonnet için birim test çerçevesi.
  2. Kaynak başlatıldığında yürütülen komut dosyalarına yönelik testler. Komut dosyaları Python'da yazılmıştır ve bu nedenle üzerlerine testler yazılabilir.
• Testlerde konfigürasyonu kontrol etmek potansiyel olarak mümkündür, ancak bunu yapmıyoruz. Ayrıca kaynak yapılandırma kurallarının kontrol edilmesini yapılandırmak da mümkündür. çakmaktaşı. Bununla birlikte, buradaki kontroller terraform için çok basit, ancak birçok test komut dosyası AWS için yazılmıştır. Ve biz Azure'dayız, yani bu yine geçerli değil.
• Bileşen entegrasyon testleri: onları nasıl sınıflandırdığınıza ve nereye koyduğunuza bağlıdır. Ama temelde çalışıyorlar.

  Entegrasyon testleri böyle görünür.

  
  
  Bu, Drone CI'da görüntüler oluşturmanın bir örneğidir. Onlara ulaşmak için Packer görüntüsünün oluşması için 30 dakika beklemeniz, ardından geçmesi için 15 dakika daha beklemeniz gerekir. Ama onlar var!

  Görüntü doğrulama algoritması

  1. Packer'ın öncelikle görüntüyü tamamen hazırlaması gerekir.
  2. Testin yanında, bu görüntüyü dağıtmak için kullandığımız yerel duruma sahip bir terraform var.
  3. Açılırken, görüntüyle çalışmayı kolaylaştırmak için yakınlarda bulunan küçük bir modül kullanılır.
  4. VM görüntüden dağıtıldıktan sonra kontroller başlayabilir. Temel olarak kontroller araba ile yapılır. Komut dosyalarının başlangıçta nasıl çalıştığını ve arka plan programlarının nasıl çalıştığını kontrol eder. Bunu yapmak için ssh veya winrm aracılığıyla yeni yükseltilmiş makineye giriş yapıyoruz ve yapılandırma durumunu veya hizmetlerin çalışıp çalışmadığını kontrol ediyoruz.

• Terraform modüllerindeki entegrasyon testlerinde de durum benzerdir. Burada bu tür testlerin özelliklerini açıklayan kısa bir tablo bulunmaktadır.

  
  
  Boru hattına ilişkin geri bildirim yaklaşık 40 dakikadır. Her şey çok uzun bir süre oluyor. Regresyon için kullanılabilir ancak yeni gelişmeler için genellikle gerçekçi değildir. Eğer buna çok ama çok hazırlıklıysanız çalışan scriptler hazırlayın, o zaman bu süreyi 10 dakikaya düşürebilirsiniz. Ancak bunlar hala 5 saniyede 100 parça yapan Birim testleri değil.

Görüntüleri veya dünya biçimi modüllerini birleştirirken Birim testlerinin bulunmaması, işin yalnızca REST aracılığıyla çalıştırılabilen ayrı hizmetlere veya Python komut dosyalarına kaydırılmasını teşvik eder.

Örneğin, sanal makinenin başlatıldığında kendisini hizmete kaydettirdiğinden emin olmamız gerekiyordu. ScaleFTve sanal makine yok edildiğinde kendini sildi.

ScaleFT'i bir hizmet olarak aldığımız için API aracılığıyla onunla çalışmak zorunda kalıyoruz. Orada, çekip şöyle diyebileceğiniz bir ambalaj kağıdı vardı: "İçeri girin ve şunu şunu silin." Gerekli tüm ayarları ve erişimleri saklar.

Bunun için zaten normal testler yazabiliyoruz, çünkü sıradan yazılımlardan hiçbir farkı yok: bir tür apiha ile alay ediliyor, onu çekiyorsunuz ve ne olduğunu görüyorsunuz.

Testlerin sonuçları: İşletim sistemini bir dakika içinde vermesi gereken birim testi bunu vermiyor. Piramidin üst kısımlarında yer alan test türleri etkilidir ancak sorunların yalnızca bir kısmını kapsar.

Çiftler programı

Testler elbette iyi. Birçoğunu yazabilirsiniz, farklı türlerde olabilirler. Kendi seviyelerinde çalışacaklar ve bize geri bildirimde bulunacaklar. Ancak en hızlı işletim sistemini sağlayan kötü Birim testleriyle ilgili sorun devam ediyor. Aynı zamanda, çalışması kolay ve keyifli, hızlı bir işletim sistemi istiyorum. Ortaya çıkan çözümün kalitesinden bahsetmiyorum bile. Neyse ki birim testlerden daha hızlı geri bildirim sağlayabilecek teknikler var. Bu çift programlamadır.

Kod yazarken kalitesine ilişkin mümkün olduğunca çabuk geri bildirim almak istersiniz. Evet, her şeyi bir özellik dalına yazabilirsiniz (kimsenin hiçbir şeyi bozmaması için), Github'da bir çekme isteği yapabilir, bunu fikri önemli olan birine atayabilir ve yanıt bekleyebilirsiniz.

Ama uzun süre bekleyebilirsiniz. İnsanların hepsi meşgul ve cevap, bir cevap olsa bile, en yüksek kalitede olmayabilir. Yanıtın anında geldiğini, incelemeyi yapan kişinin tüm fikri anında anladığını, ancak yanıtın yine de geç geldiğini varsayalım. Keşke daha erken olsaydı. Eşli programlamanın hedeflendiği şey budur - bu yazının yazıldığı anda.

Aşağıda çift programlama stilleri ve bunların IaC üzerinde çalışırken uygulanabilirliği verilmiştir:

1. Klasik, Tecrübeli+Tecrübeli, zamanlayıcıya göre geçiş. İki rol – sürücü ve gezgin. İki insan. Aynı kod üzerinde çalışırlar ve önceden belirlenmiş belirli bir sürenin ardından rol değiştirirler.

Sorunlarımızın üslupla uyumluluğunu düşünelim:

• Sorun: Kod geliştirmeye yönelik araç ve araçların kusurlu olması.
  Olumsuz etki: Gelişmek daha uzun sürüyor, yavaşlıyoruz, işin temposu/ritmi kayboluyor.
  Nasıl savaşıyoruz: Farklı bir araç, ortak bir IDE kullanıyoruz ve ayrıca kısayolları öğreniyoruz.
• Sorun: Yavaş dağıtım.
  Olumsuz etki: Çalışan bir kod parçası oluşturmak için gereken süreyi artırır. Beklerken sıkılırız, beklerken başka bir şey yapmak için ellerimiz uzanır.
  Nasıl savaşıyoruz: üstesinden gelmedik.
• Sorun: yaklaşım ve uygulamaların eksikliği.
  Olumsuz etki: Nasıl iyi yapılacağına ve nasıl kötü yapılacağına dair hiçbir bilgi yoktur. Geri bildirim alma süresini uzatır.
  Nasıl savaşırız: İkili çalışmada karşılıklı görüş ve uygulama alışverişi neredeyse sorunu çözer.

Bu tarzı IaC'de kullanmanın temel sorunu, eşit olmayan çalışma temposudur. Geleneksel yazılım geliştirmede oldukça tekdüze bir hareket vardır. Beş dakika ayırıp N yazabilirsiniz. 10 dakika harcayıp 2N, 15 dakika - 3N yazabilirsiniz. Burada beş dakikanızı ayırıp N yazabilirsiniz, sonra 30 dakika daha harcayıp N'nin onda birini yazabilirsiniz. Burada hiçbir şey bilmiyorsunuz, sıkışıp kaldınız, aptal. Soruşturma zaman alır ve dikkati programlamanın kendisinden uzaklaştırır.

Sonuç: Saf haliyle bizim için uygun değildir.

2. Masa tenisi. Bu yaklaşım, bir kişinin testi yazmasını ve diğerinin bunun için uygulamasını yapmasını içerir. Birim testlerinde her şeyin karmaşık olduğu ve programlanması uzun süren bir entegrasyon testi yazmanız gerektiği gerçeğini hesaba katarsanız, pinponun tüm kolaylığı ortadan kalkar.

Bir test betiği tasarlamak ve bunun için kod uygulamak için sorumlulukları ayırmaya çalıştığımızı söyleyebilirim. Bir katılımcı senaryoyu ortaya attı, işin sorumlu olduğu bu bölümünde son sözü o söyledi. Diğeri ise uygulamadan sorumluydu. İyi sonuç verdi. Bu yaklaşımla senaryonun kalitesi artar.

Sonuç: ne yazık ki, işin hızı pinponun IaC'de eşli programlama uygulaması olarak kullanılmasına izin vermiyor.

3.Güçlü Stil. Zor uygulama. Buradaki fikir, bir katılımcının yönerge gezgini olması ve ikincisinin yürütme sürücüsü rolünü üstlenmesidir. Bu durumda karar verme hakkı yalnızca gezgine aittir. Sürücü yalnızca yazdırır ve bir kelimeyle olup bitenleri etkileyebilir. Roller uzun süre değişmiyor.

Öğrenmek için iyidir ancak güçlü sosyal beceriler gerektirir. İşte tam bu noktada tökezledik. Teknik zordu. Ve bu altyapıyla ilgili bile değil.

Sonuç: Potansiyel olarak kullanılabilir, denemekten vazgeçmiyoruz.

4. Mobbing, swarming ve bilinen ancak listelenmeyen tüm stiller Bunu dikkate almıyoruz çünkü Biz bunu denemedik ve işimiz bağlamında bundan bahsetmek mümkün değil.

Eşli programlamanın kullanımına ilişkin genel sonuçlar:

• Dengesiz bir çalışma tempomuz var ve bu da kafa karıştırıcı.
• Yeterince iyi olmayan sosyal becerilerle karşılaştık. Ve konu alanı bu eksikliklerimizi gidermeye yardımcı olmuyor.
• Uzun testler ve araçlarla ilgili sorunlar, eşleştirilmiş geliştirmeyi zorlaştırır.

5. Buna rağmen başarılar elde edildi. Kendi yöntemimiz olan “Yakınsama – Iraksama”yı bulduk. Nasıl çalıştığını kısaca anlatacağım.

Birkaç günlüğüne (bir haftadan az) kalıcı ortaklarımız var. Birlikte bir görev yapıyoruz. Bir süre birlikte oturuyoruz: Biri yazıyor, diğeri oturup destek ekibini izliyor. Sonra bir süre dağılırız, her birimiz bağımsız şeyler yaparız, sonra tekrar bir araya geliriz, çok hızlı bir şekilde senkronize olur, birlikte bir şeyler yapar ve tekrar dağılırız.

Planlama ve iletişim

İşletim sistemi sorunlarının çözüldüğü son uygulama bloğu, işin bizzat görevlerle düzenlenmesidir. Bu aynı zamanda ikili çalışmanın dışındaki deneyim alışverişini de içerir. Şimdi üç uygulamaya bakalım:

1. Hedef ağacı aracılığıyla hedefler. Projenin genel yönetimini sonsuz geleceğe uzanan bir ağaç üzerinden organize ettik. Teknik olarak takip Miro'da yapılıyor. Bir görev var - bu bir ara hedef. Bundan ya daha küçük hedefler ya da görev grupları çıkar. Görevlerin kendisi onlardan geliyor. Tüm görevler bu panoda oluşturulur ve korunur.

Bu şema ayrıca, mitinglerde senkronize olduğumuzda günde bir kez gerçekleşen geri bildirimi de sağlar. Herkesin önünde ortak, ancak yapılandırılmış ve tamamen açık bir planın olması, herkesin olup bitenin ve ne kadar ilerlediğimizin farkında olmasını sağlar.

Görevlerin görsel vizyonunun avantajları:

• Nedensellik. Her görev bazı küresel hedeflere yol açar. Görevler daha küçük hedefler halinde gruplandırılmıştır. Altyapı alanının kendisi oldukça tekniktir. Örneğin başka bir nginx'e geçişle ilgili bir runbook yazmanın işletme üzerinde ne gibi spesifik bir etki yaratacağı her zaman hemen belli olmaz. Hedef kartın yakında olması durumu daha net hale getirir.
  
  Nedensellik problemlerin önemli bir özelliğidir. Doğrudan şu soruyu yanıtlıyor: “Doğru olanı mı yapıyorum?”
• Paralellik. Dokuz kişiyiz ve herkesi tek bir göreve vermek fiziksel olarak imkansız. Tek bir alandaki görevler de her zaman yeterli olmayabilir. Küçük çalışma grupları arasındaki çalışmaları paralelleştirmek zorunda kalıyoruz. Aynı zamanda gruplar bir süre görevlerine otururlar, başka biri tarafından takviye edilebilirler. Bazen insanlar bu çalışma grubundan uzaklaşıyorlar. Birisi tatile gidiyor, birisi DevOps konferansı için rapor hazırlıyor, birisi Habr hakkında bir makale yazıyor. Hangi hedeflerin ve görevlerin paralel olarak yapılabileceğini bilmek çok önemli hale geliyor.

2. Sabah toplantılarının yedek sunucuları. Stand-up'larda bu sorunu yaşıyoruz; insanlar birçok görevi paralel olarak yapıyor. Bazen görevler birbiriyle gevşek bir şekilde bağlantılıdır ve kimin ne yaptığına dair hiçbir anlayış yoktur. Ve başka bir ekip üyesinin görüşü çok önemlidir. Bu, sorunun çözüm sürecini değiştirebilecek ek bilgidir. Tabii ki, genellikle yanınızda biri olur, ancak tavsiye ve ipuçları her zaman faydalıdır.

Bu durumu iyileştirmek için “Öncü Stand-Up'ı Değiştirme” tekniğini kullandık. Artık belli bir listeye göre rotasyona tabi tutuluyorlar ve bunun da etkisi oluyor. Sıra size geldiğinde, iyi bir Scrum toplantısı yürütmek için konuya dalmanız ve neler olduğunu anlamanız gerekir.

3. Dahili demo. Eşli programlama yoluyla bir problemin çözümünde yardım, problem ağacında görselleştirme ve sabahki scrum toplantılarında yardım iyidir, ancak ideal değildir. Bir çift olarak yalnızca bilginizle sınırlısınız. Görev ağacı kimin ne yaptığını küresel olarak anlamaya yardımcı olur. Ve sabah toplantısında sunum yapan kişi ve meslektaşları sorunlarınızın derinliklerine dalmayacaklar. Kesinlikle bir şeyleri kaçırabilirler.

Çözüm, yapılan çalışmaların birbirlerine gösterilmesi ve ardından tartışılmasında bulundu. Haftada bir kez bir saatliğine buluşuyoruz ve geçen hafta yaptığımız işlerin çözümlerinin ayrıntılarını gösteriyoruz.

Gösteri sırasında görevin ayrıntılarını ortaya çıkarmak ve işleyişini gösterdiğinizden emin olmak gerekir.

Rapor bir kontrol listesi kullanılarak yapılabilir.1. Bağlama girin. Görev nereden geldi, neden gerekliydi?

2. Sorun daha önce nasıl çözülüyordu? Örneğin, fareye çok fazla tıklamak gerekiyordu ya da herhangi bir şey yapmak imkansızdı.

3. Bunu nasıl geliştiririz? Örneğin: “Bak, şimdi scriptosik var, işte benioku.”

4. Nasıl çalıştığını gösterin. Bazı kullanıcı senaryolarının doğrudan uygulanması tavsiye edilir. X'i istiyorum, Y'yi yapıyorum, Y'yi (veya Z'yi) görüyorum. Örneğin, NGINX'i dağıtıyorum, URL'yi içiyorum ve 200 OK alıyorum. Eylem uzunsa, daha sonra gösterebilmek için önceden hazırlayın. Eğer kırılgansa demodan bir saat önce çok fazla kırmamanız tavsiye edilir.

5. Sorunun ne kadar başarılı bir şekilde çözüldüğünü, hangi zorlukların devam ettiğini, nelerin tamamlanmadığını, gelecekte ne gibi iyileştirmelerin mümkün olduğunu açıklayın. Mesela şimdi CLI, sonra CI'da tam otomasyon olacak.

Her konuşmacının bu süreyi 5-10 dakika tutması tavsiye edilir. Konuşmanız açıkça önemliyse ve daha uzun sürecekse, bunu önceden sre-devralma kanalında koordine edin.

Yüz yüze kısımdan sonra başlıkta her zaman bir tartışma olur. Görevlerimiz hakkında ihtiyaç duyduğumuz geri bildirimin ortaya çıktığı yer burasıdır.

Sonuç olarak, olup bitenlerin yararlılığını belirlemek için bir anket yapılır. Bu, konuşmanın özüne ve görevin önemine ilişkin geri bildirimdir.

Uzun sonuçlar ve sırada ne var

Makalenin tonu biraz karamsar gibi görünebilir. Bu yanlış. Geri bildirimin iki alt düzeyi, yani testler ve eşli programlama çalışır. Geleneksel gelişimdeki kadar mükemmel olmasa da bunun olumlu bir etkisi var.

Testler mevcut haliyle yalnızca kısmi kod kapsamı sağlar. Birçok yapılandırma işlevi test edilmeden kalır. Kod yazarken asıl işe olan etkileri düşüktür. Ancak entegrasyon testlerinin etkisi vardır ve korkusuzca yeniden düzenleme yapmanıza olanak tanır. Bu büyük bir başarıdır. Ayrıca odak noktasının üst düzey dillerde (python'umuz var, go) geliştirilmesine kaydırılmasıyla sorun ortadan kalkıyor. Ve "yapıştırıcı" için çok fazla kontrole ihtiyacınız yok; genel bir entegrasyon kontrolü yeterlidir.

Çiftler halinde çalışmak daha çok belirli kişilere bağlıdır. Görev faktörü ve sosyal becerilerimiz var. Bazı insanlarda bu çok iyi sonuç verirken bazılarında ise daha kötü sonuç verir. Bunun kesinlikle faydaları var. İkili çalışma kurallarına yeterince uyulmasa bile, görevlerin birlikte yapılmasının sonucun kalitesi üzerinde olumlu bir etkisi olduğu açıktır. Şahsen ben çiftler halinde çalışmayı daha kolay ve keyifli buluyorum.

İşletim sistemini etkilemenin daha üst düzey yolları - görevleri planlamak ve bunlarla çalışmak tam olarak etkiler yaratır: yüksek kaliteli bilgi alışverişi ve gelişmiş geliştirme kalitesi.

Tek satırda kısa sonuçlar

• İK uygulayıcıları IaC'de çalışır ancak daha az verimlilikle çalışırlar.
• İşe yarayan şeyleri güçlendirin.
• Kendi telafi edici mekanizmalarınızı ve uygulamalarınızı geliştirin.

Kaynak: habr.com