Kod olarak altyapı, yapılarınızı otomatikleştiren araçları kullanmamızı söyler. Harika. Ansible , chef , kukla , tuz yığını ve diğerleri gibi araçlar bizi farklılıkları çözerken altyapının nasıl göründüğünü yazmaya doğru itiyor.
Tuz Yığını'nda bu bitlere durum denir . Eğer durum gerçeklikle uyuşmuyorsa, araç bunu bizim için çözecektir. Başka bir deyişle - altyapımız için bir test yazıyoruz ve test başarısız olursa, araç bunu kendi başına düzeltir. En azından fikir bu.
XP bize TDD'yi kullanmayı öğretiyor ve soru altyapıya uygulanabilir mi? Takım öyle olduğunu gösteriyor.
Çok yararlı olabilecek birkaç tür test hayal edebiliyorum.
Konuşlandırılan hizmetin uçtan uca beklendiği gibi çalıştığından ve çalıştığından emin olmak için konuşlandırılmış hizmetle birlikte verilen duman testleri yazıyoruz. Bu, dağıttığımız şeyin işe yaradığından emin olmak için bir API çağrısı veya / ve systemctl kontrolü olacaktır. Ansible gibi araçların bir hizmetin çalıştığından emin olmak için durumları olduğundan bu işlevselliklerin çoğu aynı durumlarda ele alınabilir.
Liman işçisine veya başka bir geçici sanallaştırma motoruna karşı bireysel rollerin (durumlarını sesli olarak çağırdığı gibi) çalıştırmaya izin veren Molekül projesi vardır . Bu, rolleri ayırmaya zorlar ve üzerinde çalışırken oyun kitabından ayrı olarak yürütülmelerine izin verir. Testler çoğunlukla rolün çalışması gereken değişkenlerin alay edilmesine izin verir. Diğer örnekler, ansible motorun bir kopyası gibi görünmektedir (bir dosyanın bir kullanıcıya ait olduğunu iddia edin ...).
ThoughtWorks teknoloji radarı şu anda sunucunun teknik özellikleri karşıladığını doğrulamak için inspec , serverspec veya goss gibi araçları övüyor . Ama bir özellik yazıyoruz, değil mi?
Peki, eyaletlerde / rollerdeki altyapıyı açıklıyorsak, altyapıyı daha fazla test etmenin bir anlamı var mı? Bunun, bir takımın spesifikasyonu ve diğerlerini sağladığı daha büyük organizasyonlarda daha gerekli hale gelebileceğinden şüphelenebilirim ya da çok sayıda rol varsa, belki de bunların bir alt kümesini çalıştırmak ve testlerden hızlı bir şekilde yararlanmak istersiniz? Akılda aynı soru için bir rol / durumunuz varsa neden bir test yazacağınızı görmek için uğraşıyorum.
goss. Bu nedenle, örneğin, RPM yüklenir (ansible) ve daha sonra beklenen varsayılan dosya yerleştirilirse veya hizmet belirli bir bağlantı noktasını çalıştırıyor ve dinliyorsa test edilir. Bu sorunu otomatik olarak düzeltmek istemiyorum, ancak haberdar edilmek ve ilerlemeyi durdurmak istiyorum. Elbette Ansible sistemi sizin için de test edebilir, sadece açık olmanız gerekir, ancak bizim durumumuzda,gossbir kap içindeki hizmet davranışını test etmek için kullanırız