Altyapıyı dağıtmak için kukla kullanıyorum ve yaptığım işlerin çoğu, web uygulamaları için test odaklı geliştirmeye yoğunlaşan Web 2.0 şirketleriyle. Burada kimse sunucu yapılandırmalarını geliştirmek için test odaklı bir yaklaşım kullanıyor mu? Bunu yapmak için hangi araçları kullanıyorsunuz? Testiniz ne kadar derine gidiyor?
Yanıtlar:
Test odaklı geliştirmeyi kullanabileceğinizi sanmıyorum . Ancak yeni sunucularda kesinlikle birim test etmeyi deneyebilirsiniz .
Temel olarak sunucuları dağıtmanız, hizmetleri bir test modunda başlatmanız ve daha sonra başka bir sunucudan (veya bir dizi sunucudan) hizmetlere karşı sınama çalıştırmanız gerekir. Sonunda onları üretime soktu.
Belki de veritabanlarına, web sayfalarına ve ssh hizmetlerine bağlanmak için python komut dosyaları kullanmaktır. Sonra bir GEÇ / BAŞARISIZ döndürün. Senin için iyi bir başlangıç olurdu.
Ya da bunu Zenoss, Nagios veya Munin gibi bir izleme çözümüne dönüştürebilirsiniz. Sonra dağıtım sırasında test edebilirsiniz; Ve üretim sırasında izlemek.
Bence Joseph Kern izleme araçlarıyla doğru yolda. Tipik TDD döngüsü: başarısız olan yeni bir test yazın, ardından mevcut tüm testlerin geçmesi için sistemi güncelleyin. Bu, Nagios'a uyum sağlamak için kolay olurdu: başarısız denetimi ekleyin, sunucuyu yapılandırın, tüm kontrolleri yeniden çalıştırın. Düşünmeye gel, bazen bunu tam olarak yaptım.
Gerçekten çok çekirdekli olmak istiyorsanız, sunucu yapılandırmalarının ilgili tüm yönlerini kontrol etmek için komut dosyaları yazdığınızdan emin olursunuz. Nagios gibi bir izleme sistemi bazılarıyla ilgili olmayabilir (örn. İşletim sistemi sürümünüzü "izlemeyebilirsiniz"), ancak uygun şekilde karıştırıp eşleştirememenizin bir nedeni yoktur.
TDD'yi henüz Kukla tezahürleri ile yapamasam da, değişikliklerin test edilmeden üretime girmesini önlemek için oldukça iyi bir döngümüz var. İki kuklacı kurduk, biri üretim kuklacı, diğeri geliştirme kuklacı. Aşağıdakileri kurmak için Kukla'nın "ortamlarını" kullanıyoruz:
Uygulama geliştiricilerimiz, çalışmalarını Kukla konfigürasyonlarını geliştirme Puppetmaster'ın "test" ortamından alan sanal makinelerde yapıyorlar. Kukla tezahürleri geliştirirken, genellikle geliştirme sürecinde test istemcisi olarak hizmet verecek bir VM kurduk ve bunu kişisel gelişim ortamımıza yönlendirdik. Tezahürlerimizden memnun olduğumuzda, onları uygulama geliştiricilerinin VM'lerindeki değişiklikleri alacağı test ortamına itiyoruz - bir şey bozulduğunda genellikle yüksek sesle şikayet ediyorlar :-)
Üretim makinelerimizin temsili bir alt kümesinde, noop modunda çalışan ve test ortamına işaret eden ikinci bir kukla var. Bunu, üretime geçmeden önce tezahürlerle ilgili potansiyel sorunları yakalamak için kullanıyoruz.
Değişiklikler geçtiğinde, yani uygulama geliştiricisinin makinelerini kırmazlar ve üretim makinelerinin "noop" kukla sürecinin günlüklerinde istenmeyen çıktı üretmezler, yeni tezahürleri üretime iteriz. Daha önceki bir sürüme geri dönebilmemiz için bir geri alma mekanizmamız var.
Bir TDD operasyon modeline geçiş sürecinde olan bir ortamda çalıştım. Betikleri izlemek gibi bazı şeyler için bu çok iyi çalıştı. Test ortamını kurmak ve testleri çalıştırmak için buildbot kullandık. Bu durumda TDD'ye "Eski Kod" perspektifinden yaklaşırsınız. TDD'de "Eski Kod" hiçbir testi olmayan mevcut koddur. İlk testler başarısız olmaz, doğru (veya beklenen) işlemi tanımlarlar.
Birçok yapılandırma işi için ilk adım, yapılandırmanın servis tarafından ayrıştırılıp ayrıştırılamayacağını test etmektir. Birçok hizmet sadece bunu yapmak için bazı olanaklar sağlar. Nagios ön kontrol moduna sahiptir, cfagent'ın bir eylemi yoktur, apache, sudo, bind ve diğer birçoklarının benzer tesisleri vardır. Bu temel olarak konfigürasyonlar için bir tiftik çalışmasıdır.
Farklı parçalar için apache ve ayrı yapılandırma dosyaları kullanırsanız, parçaları test edebilir ve test makinenizde çalıştırmak için sarmak için sadece farklı bir httpd.conf dosyası kullanabilirsiniz. Ardından, test makinesindeki web sunucusunun orada doğru sonuçları verdiğini test edebilirsiniz.
Yoldaki her adım aynı temel modeli izler. Bir test yazın, test geçişini yapın, yaptığınız işi yeniden düzenleyin. Yukarıda belirtildiği gibi, bu yolu takip ederken, testler her zaman kabul edilen TDD tarzında başarısız olmayabilir.
Rik
Aşağıdaki bağlantıların ilgi çekici olabileceğine inanıyorum
cucumber-nagios - Salatalık paketinizi Nagios eklentisine dönüştürmenizi sağlayan ve SSH, DNS, Ping, AMQP ve genel "yürütme komutu" görev türleri için adım tanımlarıyla birlikte gelen proje
http://auxesis.github.com/cucumber- nagios /
http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
http://agilesysadmin.net/cucumber-nagios
Kukla / Python tarafında da bazı çabalar var http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php