ฉันควรรวมการทดสอบในอิมเมจ Docker หรือไม่


19

เมื่อพูดถึงการทดสอบฉันสามารถนึกถึงสองตัวเลือก:

  1. ใส่ทั้งการทดสอบและแอปพลิเคชันในภาพเดียว
  2. รวมเฉพาะรหัสแอปพลิเคชันในภาพ สร้างคอนเทนเนอร์เฉพาะของการทดสอบที่สร้างขึ้นหลังจากอิมเมจหลักและเพิ่มเลเยอร์บางอย่างลงในนั้น (รหัสทดสอบการอ้างอิงและอื่น ๆ )

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

ด้วยตัวเลือกที่สองรูปภาพที่ส่งมานั้นไม่เหมือนกับภาพที่ถูกทดสอบ

ทั้งคู่ดูเหมือนกลยุทธ์ที่ไม่ดี มีสามกลยุทธ์ที่ดีกว่าหรือไม่?


1
คุณตอบเอง ทั้งคู่เป็นความคิดที่ไม่ดี คุณจะจัดส่งกระบวนการที่รันได้ที่ทดสอบแล้วไปยังขนาดคอนเทนเนอร์และปรับแต่งตามความต้องการ คุณไม่ต้องการ dev-dependencies หรือ src code ในการผลิตถือว่าเป็นความเสี่ยง
Laiv

1
การทดสอบก่อนการบรรจุขวดหมายความว่าสภาพแวดล้อมไม่ได้ทดสอบเฉพาะรหัสเท่านั้น คุณจะได้ทดสอบเพียงส่วนหนึ่งของสิ่งที่คุณจัดส่งไม่ใช่ทั้งหมด
lfk

คำตอบ:


10

สำหรับการทดสอบการทำงานเวลาสร้างวิธีการที่ต้องการจะใช้แบบหลายขั้นตอนการสร้าง Multi-stage Dockerfiles ช่วยให้คุณมีสเตจขนาดใหญ่พร้อมการพึ่งพาทั้งหมดสำหรับการสร้างและการทดสอบจากนั้นคัดลอกสิ่งประดิษฐ์ที่แน่นอนที่คุณทดสอบไปยังสเตจอื่นสำหรับอิมเมจรันไทม์ที่มีขนาดเล็กลง

คุณต้องการทดสอบระดับระบบของคอนเทนเนอร์หลายตัวโดยใช้อินเตอร์เฟสภายนอกแทนที่จะรันภายในคอนเทนเนอร์ เนื่องจากการทดสอบเหล่านั้นเกี่ยวข้องกับการประสานงานระหว่างการบริการจำเป็นต้องมีการพึ่งพาที่แตกต่างกันเช่นการเข้าถึง orchestration ของคุณจึงไม่เหมือนกับการทดสอบแบบ build-time และมักจะเขียนเป็นภาษาที่แตกต่างกันโดยสิ้นเชิงดังนั้นจึงไม่ใช่เรื่องใหญ่ ภาชนะที่ทุ่มเทให้กับการทดสอบระบบ


1
ดังนั้นนั่นเป็นตัวเลือกที่ค่อนข้างดี 2 - ฉันทำการทดสอบในสภาพแวดล้อม / ภาชนะบรรจุที่คล้ายกับการผลิต แต่ไม่เหมือนกัน นั่นถูกต้องใช่ไหม?
lfk

9

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

TL; DR;

ในระยะสั้นคุณต้องแยก:

  • รหัสของคุณจาก
  • การกำหนดค่าแอปพลิเคชันจาก
  • การกำหนดค่าสภาพแวดล้อมระบบ

แต่ละคนต้องเป็นอิสระจากกันและเหมาะสม:

  • ควบคุมเวอร์ชัน
  • การทดสอบ
  • deployable

รุ่นที่ยาวกว่า

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

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

สุดท้ายแล้วขั้นตอนต่อไปคือที่ที่คุณสร้างสภาพแวดล้อม (ระบบ) ของคุณราวกับว่ามันกำลังใช้งานจริง หากคุณกำลังใช้ Docker ในการผลิตนี่คือที่ที่คุณจะนึกถึงความปลอดภัยของเครือข่ายและการปรับแต่งเซิร์ฟเวอร์ ฯลฯ รูปภาพ Docker ของคุณอาจเป็นไปตามที่คุณใช้ในการพัฒนา (ตามอุดมคติ) แต่อาจมีการเปลี่ยนแปลงสำหรับการปรับขนาดและความปลอดภัย , ที่ผมกล่าวว่า. ถึงตอนนี้การทดสอบการใช้งานของแอพพลิเคชั่นจะเสร็จสมบูรณ์คุณกังวลเรื่องความปลอดภัยและประสิทธิภาพมากกว่า จากการทดสอบการใช้งานการทดสอบของคุณที่นี่สามารถพัฒนาติดตั้งและรันได้จากอิมเมจ Docker อื่น ๆ ขั้นตอนนี้เคยมีราคาแพงมากและไม่ค่อยทำเช่นนั้นคุณจึงจำเป็นต้องใช้ฮาร์ดแวร์เฉพาะในสถานที่ที่ผลิตซ้ำ วันนี้สิ่งนี้สามารถทำงานได้อย่างสมบูรณ์เพราะคุณสามารถยืนหยัดและทำลายสภาพแวดล้อมทั้งหมดในเกือบทุกขนาดตามความต้องการ

ในที่สุดคุณมีการเปิดตัวที่ควรจะผลิตพร้อมกับชุดของการตั้งค่าเพียงเล็กน้อยเดลต้าจากการทดสอบการรวมของคุณ (ที่อยู่ IP, ฐานข้อมูล URI, รหัสผ่านและอื่น ๆ ) ฐานรหัสของคุณได้รับการทดสอบอย่างน้อยสามสภาพแวดล้อม จุดและส่วนใหญ่ของการกำหนดค่าระบบอย่างน้อยหนึ่งครั้ง


นั่นหมายความว่า CI ของคุณจะไม่ทำการทดสอบ Dockerfiles เลยหรือ? ตัวอย่างเช่นหาก Dockerfile ของคุณไม่มีการพึ่งพาการทดสอบจะยังคงผ่าน?
lfk

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

0

ฉันคิดว่าคุณกำลังผสมการทดสอบประเภทต่างๆ โดยทั่วไปคุณต้องถามตัวเอง: หน่วยทดสอบที่นี่คืออะไร

สถานการณ์ที่พบบ่อยที่สุดเมื่อคุณทำงานในฐานะนักพัฒนาคือการเขียนการทดสอบหน่วย / การรวมสำหรับโค้ดบางส่วนที่คุณกำลังทำงานอยู่โดยที่โค้ดนั้นเป็นหน่วยที่กำลังทดสอบ คุณเรียกใช้การทดสอบเหล่านั้นในเครื่องและ / หรือใน CI

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

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

ดังนั้นฉันคิดว่าตัวเลือกที่ 3 ที่คุณกำลังมองหาคือ:

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

ดังนั้นขั้นตอน CI / CD จะเป็น:

สภาพแวดล้อมการพัฒนาติดตั้ง -> ทำการทดสอบด้วยรหัส -> สร้างภาพสุดท้าย -> ทำการทดสอบบนภาพ -> ปรับใช้ภาพ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.