โครงสร้างพื้นฐานเป็นรหัสและ TDD

11

โครงสร้างพื้นฐานเป็นรหัสบอกให้เราใช้เครื่องมือที่ทำให้งานสร้างของคุณเป็นแบบอัตโนมัติ ยิ่งใหญ่ เครื่องมืออย่างansible , พ่อครัว , หุ่นเชิด , กองเกลือและอื่น ๆ ผลักดันเราให้เขียนว่าโครงสร้างพื้นฐานมีลักษณะอย่างไรในขณะที่แก้ไขความแตกต่าง

ใน Salt กองบิตเหล่านี้จะเรียกว่ารัฐ หากรัฐไม่ตรงกับความจริงเครื่องมือจะแก้ไขให้เรา กล่าวอีกนัยหนึ่ง - เรากำลังเขียนการทดสอบสำหรับโครงสร้างพื้นฐานของเราและหากการทดสอบล้มเหลวเครื่องมือจะแก้ไขด้วยตนเอง อย่างน้อยนั่นก็เป็นความคิด

XP สอนให้เราใช้ TDD และคำถามคือถ้ามันใช้กับโครงสร้างพื้นฐานได้หรือไม่ การขับรถแสดงให้เห็นว่ามันเป็น

ฉันนึกภาพการทดสอบบางประเภทที่มีประโยชน์มาก

เราเขียนการทดสอบควันที่มาพร้อมกับบริการที่ปรับใช้เพื่อให้แน่ใจว่าบริการที่ปรับใช้แบบ end-to-end จะทำงานและทำงานตามที่คาดไว้ นี่จะเป็นการเรียก API หรือ / และ systemctl ตรวจสอบเพื่อให้แน่ใจว่าสิ่งที่เราเพิ่งปรับใช้งาน ฟังก์ชั่นจำนวนมากนี้สามารถครอบคลุมในสถานะเดียวกันเนื่องจากเครื่องมือเช่น ansible มีสถานะเพื่อให้แน่ใจว่าบริการกำลังทำงานอยู่

มีโครงการโมเลกุลที่อนุญาตให้เรียกใช้แต่ละบทบาท (ตามที่เรียกว่าสถานะของมัน) เทียบกับนักเทียบท่าหรือเครื่องมือ virtualisation ชั่วคราวอื่น กองกำลังนี้จะแยกบทบาทและอนุญาตให้ดำเนินการแยกจาก playbook ขณะที่ทำงานกับพวกเขา การทดสอบส่วนใหญ่อนุญาตการเยาะเย้ยตัวแปรที่บทบาทควรจะทำงานด้วย ตัวอย่างอื่น ๆ ดูเหมือนจะซ้ำซ้อนของเอ็นจิน ansible (ยืนยันไฟล์ที่เป็นของผู้ใช้ ... )

เรดาร์เทคโนโลยีของThoughtWorksในขณะนี้ยกย่องเครื่องมือเช่นinspec , serverspecหรือgossสำหรับการตรวจสอบว่าเซิร์ฟเวอร์นั้นตรงตามข้อกำหนด แต่เรากำลังเขียนสเป็คใช่มั้ย

ดังนั้นจะมีจุดหนึ่งในการทดสอบโครงสร้างพื้นฐานเพิ่มเติมหากเราอธิบายโครงสร้างพื้นฐานในรัฐ / บทบาทหรือไม่? ฉันสงสัยว่าสิ่งนี้จะกลายเป็นสิ่งจำเป็นมากขึ้นในองค์กรขนาดใหญ่ที่ทีมใดทีมหนึ่งให้ข้อมูลจำเพาะและอื่น ๆ ตามมาหรือหากมีบทบาทจำนวนมากบางทีคุณอาจต้องการเรียกใช้ชุดย่อยเหล่านั้นและได้รับประโยชน์จากการทดสอบเร็ว ฉันกำลังดิ้นรนเพื่อดูว่าทำไมคุณถึงเขียนข้อสอบหากคุณมีบทบาท / สถานะสำหรับคำถามเดียวกันในใจ

— JackLeo
แหล่งที่มา

6

โดยสรุปฉันเห็นการทดสอบสองประเภทสำหรับโครงสร้างพื้นฐานของคุณ: 1) มีทุกสิ่งที่คุณต้องการในการเรียกใช้แอปพลิเคชันของคุณหรือไม่ 2) ไม่มีสิ่งที่ไม่จำเป็น

ก่อนอื่นคุณสามารถใช้ชุดทดสอบของซอฟต์แวร์จริงเป็น "meta test" สำหรับโครงสร้างพื้นฐานของคุณ ตราบใดที่คุณสร้างโครงสร้างพื้นฐานตั้งแต่เริ่มต้นสำหรับการทดสอบแต่ละครั้งและชุดการทดสอบจะทำงานอย่างสมบูรณ์บนโครงสร้างพื้นฐานนั้น (เช่นไม่ได้ใช้บริการภายนอก) ข้อเท็จจริงที่ว่าชุดทั้งหมดเป็นสีเขียวหมายความว่าโครงสร้างพื้นฐานประมวลผลของคุณก็เพียงพอแล้วเช่นกัน .

ประการที่สองโดยเฉพาะจากมุมมองด้านความปลอดภัยคุณสามารถเขียนทดสอบกับโครงสร้างพื้นฐานของคุณ นั่นคือถ้าส่วนหนึ่งของโครงสร้างพื้นฐานของคุณคือ VM ที่ใช้ Linux คุณอาจเขียนการทดสอบที่ทำการสแกนพอร์ตจาก VM นั้นเพื่อให้แน่ใจว่าไม่มีพอร์ตที่ไม่ตั้งใจเปิดอยู่ซึ่งอาจติดตั้งโดยผลapt-get installข้างเคียงที่ไม่ได้ตั้งใจ. หรือคุณสามารถเขียนการทดสอบที่ตรวจสอบว่ามีการเปลี่ยนแปลงไฟล์ที่ไม่คาดคิดหลังจากชุดทดสอบที่เหมาะสมของคุณเสร็จสมบูรณ์หรือไม่ หรือคุณสามารถตรวจสอบpsผลลัพธ์ของ VMs หรือ Docker container ของคุณสำหรับกระบวนการที่ไม่คาดคิดและสร้างรายการสีขาว ฯลฯ และรับการแจ้งเตือนอัตโนมัติหากแพ็คเกจบุคคลที่สามบางชุดเปลี่ยนไปในแบบไม่มีเอกสาร (หรือวิธีที่ไม่มีใครสังเกตเห็น) ในการอัปเกรด

การทดสอบประเภทที่สองเหล่านี้คล้ายกับสิ่งที่คุณจะทำในการตั้งค่า ops แบบคลาสสิกอย่างไรก็ตามคือการทำให้เซิร์ฟเวอร์ของคุณแข็งและตรวจสอบการบุกรุกหลีกเลี่ยงทรัพยากรที่เต็มไป

— AnoE
แหล่งที่มา

หลังจากผ่านไประยะหนึ่งนี่เป็นท่าทางที่ฉันได้ทำ ส่วนที่มีการดำเนินการโดยเบิ้ลยังไม่ได้ผ่านการทดสอบด้วยตัวเอง gossแต่ผลข้างเคียงของการกระทำเหล่านั้นจะถูกทดสอบโดยใช้ ดังนั้นสำหรับตัวอย่างเช่น RPM ได้รับการติดตั้ง (ansible) จากนั้นทดสอบว่าไฟล์เริ่มต้นที่คาดว่าจะเกิดขึ้นหรือบริการกำลังทำงานอยู่และกำลังฟังพอร์ตเฉพาะ ฉันไม่ต้องการแก้ไขปัญหาดังกล่าวโดยอัตโนมัติ แต่ได้รับแจ้งและหยุดความคืบหน้า แน่นอนว่า Ansible สามารถทดสอบระบบให้กับคุณเช่นกันคุณเพียงแค่ต้องมีความชัดเจนเกี่ยวกับเรื่องนี้ แต่ในกรณีของเราเราใช้gossเพื่อทดสอบพฤติกรรมการให้บริการภายในตู้คอนเทนเนอร์

— JackLeo

1

IMHO มันค่อนข้างซ้ำซ้อนในการเขียนการทดสอบ TDD สำหรับรายการที่ครอบคลุมโดยข้อกำหนดของรัฐ IaaC การทำเช่นนั้นบอกเป็นนัยว่าประสิทธิผลของ IaaC นั้นน่าสงสัย - ทำไมคุณถึงใช้ถ้าเป็นเช่นนั้น

ดูจาก IaaC ที่คาดหวังที่แตกต่างกันของตัวเอง (ถ้า / เมื่อทำอย่างถูกต้อง) รวมความสามารถที่ผ่านการทดสอบและพิจารณาแล้วว่าทำงานได้อย่างน่าเชื่อถือ ซึ่งเป็นสิ่งที่ทำให้มันน่าสนใจและทำให้การเขียนการทดสอบการจับคู่ TDD ซ้ำซ้อน

ตัวอย่างเช่นการกำหนดค่า IaaC ที่ระบุระบบที่มีการติดตั้ง SSH แล้วรวมการตรวจสอบที่เชื่อถือได้สำหรับ SSH ที่ติดตั้งอย่างถูกต้องและหากไม่ได้กลไกสำหรับการติดตั้งอย่างถูกต้อง ซึ่งทำให้การทดสอบ TDD สำหรับตรวจสอบว่ามีการติดตั้ง SSH ซ้ำซ้อนหรือไม่ หากการกำหนดค่า IaaC ของคุณยังระบุ sshd ที่จะเริ่มต้นและฟังพอร์ตที่เฉพาะเจาะจงจากนั้นการทดสอบ TDD สำหรับ sshd ที่ทำงานและการฟังพอร์ตที่เกี่ยวข้องก็จะซ้ำซ้อน

โปรดทราบว่าคำตอบของฉันไม่ได้กำหนดเป้าหมายเป็น TDD หรือการทดสอบประเภทอื่น ๆ ที่ตรวจสอบว่าการกำหนดค่า IaaC ของคุณโดยรวมเหมาะสมกับวัตถุประสงค์ที่แน่นอนหรือไม่ ที่ยังคงถูกต้องและสามารถใช้ใน TDD, CI หรือการตรวจสอบที่คล้ายกันในระหว่างการพัฒนาข้อกำหนด IaaC นั้น - ฉันเชื่อว่าคำตอบของ @ AnoE ใช้ในกรณีดังกล่าว

— Dan Cornilescu
แหล่งที่มา

คุณใช้ความคิดแบบเดียวกันเพื่อให้แน่ใจว่ามีการเปิดใช้งาน SSH (หรืออะไรก็ตาม) ในพอร์ตที่กำหนดเองซึ่งแยกวิเคราะห์จากไฟล์กำหนดค่าภายนอกหรือไม่ นั่นไม่ใช่การพักผ่อนในหน่วยที่ทดสอบนั่นคือตรรกะใหม่

— Jon Lauridsen

1

ควรเป็นส่วนหนึ่งของ IaaC หากรองรับ ถ้าไม่ใช่ - การสนทนานี้ไม่ได้ใช้จริงๆ ใช่สิ่งนี้สามารถเลื่อนดูว่า IaaC สามารถครอบคลุมเนื้อหาได้มากเพียงใด แต่นั่นเป็นการอภิปรายที่แตกต่างออกไป

— Dan Cornilescu

1

ฉันยังสมมติว่าเราไม่ได้อยู่ในบริบทที่ต้องการการตรวจสอบซ้ำซ้อน - ในบางกรณีการตรวจสอบซ้ำซ้อนตามเส้นทางรหัสที่แตกต่างกันโดยสิ้นเชิงหรืออาจจำเป็นต้องใช้โครงสร้างพื้นฐาน

— Dan Cornilescu

1

ดูเหมือนว่าทุกคนที่นี่ถือว่าเครื่องมือ IAC ทำงานตามที่คาดไว้เสมอ แต่ฉันสามารถบอกได้ (จากประสบการณ์ของตัวเอง) นี่ไม่ใช่กรณีเสมอมิฉะนั้นการทดสอบหน่วยจะไม่มีประโยชน์จริง ๆ

ฉันจำภาพที่เขียนว่า "เพลย์บุ๊ค Ansible วิ่งได้ทุกอย่างดี" ด้วยตึกที่ถูกเผาไหม้ในพื้นหลัง ...

การรันสถานะที่เปิดเผยและการมีเซิร์ฟเวอร์ในสถานะที่ประกาศจริงนี้เป็น 2 สิ่งที่แตกต่างจากมุมมองและประสบการณ์ของฉันอย่างน้อย

สภาพแวดล้อมที่กว้างและต่างกันแผ่กระจายไปทั่ว DC หลาย ๆ เข้าถึงได้ผ่านเครือข่ายสาธารณะ ฯลฯ ... มีหลายเหตุผลที่รัฐไม่สามารถใช้งานได้ไม่ว่าจะเต็มหรือบางส่วน

ด้วยเหตุผลทั้งหมดนี้จึงมีที่ว่างสำหรับการทดสอบหน่วยที่ให้หนึ่งสามารถรับภาพรวมของสถานะเซิร์ฟเวอร์จริงซึ่งอีกครั้งอาจแตกต่างจากสถานะที่ต้องการ

ดังนั้นฉันจะบอกว่าใช่การทดสอบหน่วยมีประโยชน์แม้ในสภาพแวดล้อมที่มีการจัดการ IAC

แก้ไข

แล้วด้านที่ไม่ใช่การถดถอยของสาขา dev ของฐานรหัส IaC ล่ะ ดังนั้นคุณจะทำการเปลี่ยนแปลงรหัสของคุณในสาขา dev และรวมเข้ากับสาขาแยงหวังว่าจะไม่ทำลายทุกอย่างหรือ การทดสอบหน่วยมีค่ามากและมักใช้งานง่ายฉันไม่เห็นสาเหตุที่จะมีรหัสโดยไม่มีคุณสมบัตินี้

ข้อมูลอ้างอิง (เป็นภาษาฝรั่งเศสขออภัยสำหรับสิ่งนั้น): https://fr.slideshare.net/logilab/testinfra-pyconfr-2017

— ตอม่อ
แหล่งที่มา

1

อย่างน้อยก็ต้องสุภาพในการเพิ่มความคิดเห็นด้วยการลงคะแนนเสียงคุณไม่คิดว่าผู้ออกเสียงลงคะแนน? โดยเฉพาะอย่างยิ่งคำถามประเภทนี้ที่การอภิปรายอาจให้ข้อมูลหรือสร้างสรรค์มาก

— ท่าเรือ

ฉันคิดว่าน้ำเสียงของคำตอบของคุณซึ่งค่อนข้างก้าวร้าวกับทุกคนที่โต้ตอบกับคำถามนี้เพิ่มเข้ากับความจริงที่ว่าคุณไม่ได้ให้การอ้างอิงใด ๆ จากตัวอย่างที่ดีของคุณเองหรืออธิบายการทำงานผิดปกติใด ๆ ในที่สุดคุณก็จบลงด้วยการพูดแบบเดียวกับคำตอบอื่น ๆ บอกว่ามีการทดสอบควันในระบบการจัดสรรของคุณเพื่อให้แน่ใจว่าระบบนั้นเป็นปกติซึ่งระบบส่วนใหญ่จะทำโดยการล้มเหลวหากพวกเขาไม่สามารถรวมระบบในสถานะที่ต้องการ เกี่ยวกับการแก้ไขของคุณโดยปกติแล้วการผสานจะเสร็จสิ้นหลังจากปรับใช้กับการจัดเตรียมและมั่นใจว่าการทดสอบควันผ่าน ...

— Tensibai

แน่นอนฉันไม่ได้ตั้งใจที่จะก้าวร้าวฉันไม่ได้ใช้ภาษา natibve ของฉันที่นี่ (เห็นได้ชัดว่าฉันเดา :))

— ท่าเรือ

เราอาจพูดคุยกันในDevOps Chatหากคุณต้องการฉันคิดว่าฉันเห็นงานนำเสนอนี้หรืออย่างใดอย่างหนึ่งในงาน devoxx เมื่อไม่กี่ปีที่ผ่านมา ฉันไม่เห็นด้วยเล็กน้อยกับการเรียกการทดสอบหน่วยนั่นคือการทดสอบที่ใช้งานได้มากกว่า

— Tensibai

บางคนจากทีม dev ของฉันบอกฉันเหมือนกันว่านี่ไม่ใช่การทดสอบหน่วยฉันไม่ใช่นักพัฒนาดังนั้นฉันอาจผิดเกี่ยวกับการเรียกการทดสอบหน่วยนี้แน่นอน

— Pier

1

จากประสบการณ์ของฉันหนึ่งในความแตกต่างที่สำคัญระหว่าง Dev และ Ops คือ "การพึ่งพาเวลาทำงานหนัก" การติดตั้งแพคเกจขึ้นอยู่กับที่เก็บเครือข่ายหรือคีย์ที่ถูกต้องเป็นอย่างมากหรือสมมติว่าสร้างอินสแตนซ์เซิร์ฟเวอร์คลาวด์ใหม่ขึ้นอยู่กับทรัพยากรของผู้ให้บริการของคุณ

ในแง่ของการจัดเตรียมเซิร์ฟเวอร์แม้ว่าคุณจะไม่ได้เปลี่ยนรหัสการจัดเตรียมรูปภาพของคุณจะใช้งานได้เกือบทุกครั้ง แต่บางครั้งก็ไม่ ดังนั้นฉันคิดว่าการทดสอบเป็นสิ่งจำเป็นอย่างยิ่งสำหรับการจัดทำรูปภาพ

หากคุณไปอยู่ในเซิร์ฟเวอร์เดียวสิ่งที่เลวร้ายยิ่งกว่าเดิม ... คุณจะทดสอบความสามารถในการเข้าถึงเครือข่ายทั้งหมดได้อย่างไร รวมถึงความละเอียด DNS การกำหนดเส้นทางและไฟร์วอลล์? แม้ว่าผู้ให้บริการ IaaC API ของคุณจะทำงานได้ตามที่คาดไว้ (ฉันเคยเห็นปัญหาเกี่ยวกับสายในพื้นที่นี้) ฉันชอบ TDD ในกรณีนี้

เนื่องจากฉันไม่พบเครื่องมือทดสอบในพื้นที่นี้เราจึงเขียนหนึ่งเครื่องมือในเวลาว่างของเรา: https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

ดังนั้นฉันคิดว่า TDD มีความสำคัญในโลก DevOps!

— jerger
แหล่งที่มา