ส่วนที่ 1: เว็บ/Android
หมายเหตุ: บทความนี้เป็นการแปลเป็นภาษารัสเซียของบทความต้นฉบับ อย่างไรก็ตาม ภาพประกอบ ลิงก์ คำพูดและคำศัพท์ทั้งหมดจะถูกเก็บรักษาไว้เป็นภาษาต้นฉบับเพื่อหลีกเลี่ยงการบิดเบือนความหมายเมื่อแปลเป็นภาษารัสเซีย ฉันขอให้คุณมีความสุขกับการเรียน!
ปัจจุบันความเชี่ยวชาญพิเศษด้าน DevOps เป็นหนึ่งในหลักสูตรที่เป็นที่ต้องการมากที่สุดในอุตสาหกรรมไอที หากคุณเปิดไซต์ค้นหางานยอดนิยมและกรองตามเงินเดือน คุณจะเห็นว่างานที่เกี่ยวข้องกับ DevOps อยู่ที่ด้านบนสุดของรายการ อย่างไรก็ตาม สิ่งสำคัญคือต้องเข้าใจว่าตำแหน่งนี้หมายถึงตำแหน่ง "อาวุโส" เป็นหลัก ซึ่งหมายความว่าผู้สมัครมีทักษะ ความรู้ด้านเทคโนโลยีและเครื่องมือในระดับสูง นอกจากนี้ยังมาพร้อมกับความรับผิดชอบระดับสูงที่เกี่ยวข้องกับการดำเนินการผลิตอย่างต่อเนื่อง อย่างไรก็ตาม เราเริ่มลืมไปแล้วว่า DevOps คืออะไร ในตอนแรกไม่ใช่บุคคลหรือแผนกใดโดยเฉพาะ ถ้าเรามองหาคำจำกัดความของคำนี้ เราจะพบคำนามที่สวยงามและถูกต้องมากมาย เช่น วิธีการ การปฏิบัติ ปรัชญาวัฒนธรรม กลุ่มของแนวคิด และอื่นๆ
ความเชี่ยวชาญของฉันคือวิศวกรทดสอบอัตโนมัติ (วิศวกรอัตโนมัติ QA) แต่ฉันเชื่อว่าไม่ควรเกี่ยวข้องกับการเขียนการทดสอบอัตโนมัติหรือการพัฒนาสถาปัตยกรรมกรอบการทดสอบเท่านั้น ในปี 2020 ความรู้เกี่ยวกับโครงสร้างพื้นฐานของระบบอัตโนมัติก็มีความสำคัญเช่นกัน สิ่งนี้ช่วยให้คุณสามารถจัดระเบียบกระบวนการอัตโนมัติได้ด้วยตัวเอง ตั้งแต่การทดสอบไปจนถึงการให้ผลลัพธ์แก่ผู้มีส่วนได้ส่วนเสียทั้งหมดตามเป้าหมายของคุณ ด้วยเหตุนี้ทักษะ DevOps จึงเป็นสิ่งจำเป็นในการทำงานให้สำเร็จ และทั้งหมดนี้เป็นสิ่งที่ดี แต่น่าเสียดายที่มีปัญหา (สปอยเลอร์: บทความนี้พยายามทำให้ปัญหานี้ง่ายขึ้น). ประเด็นก็คือ DevOps นั้นยาก และสิ่งนี้ชัดเจน เนื่องจากบริษัทต่างๆ จะไม่จ่ายเงินจำนวนมากเพื่อสิ่งที่ทำได้ง่าย... ในโลกของ DevOps มีเครื่องมือ เงื่อนไข และแนวทางปฏิบัติมากมายที่จำเป็นต้องได้รับการเรียนรู้ นี่เป็นเรื่องยากโดยเฉพาะในช่วงเริ่มต้นอาชีพและขึ้นอยู่กับประสบการณ์ทางเทคนิคที่สั่งสมมา
ที่มา:
เราอาจจะจบในส่วนเกริ่นนำและเน้นไปที่วัตถุประสงค์ของบทความนี้
บทความนี้เกี่ยวกับอะไร?
ในบทความนี้ ฉันจะแบ่งปันประสบการณ์ของฉันในการสร้างโครงสร้างพื้นฐานการทดสอบอัตโนมัติ มีแหล่งข้อมูลมากมายบนอินเทอร์เน็ตเกี่ยวกับเครื่องมือต่างๆ และวิธีการใช้งาน แต่ฉันอยากจะพิจารณาแหล่งข้อมูลเหล่านั้นในบริบทของระบบอัตโนมัติเท่านั้น ฉันเชื่อว่าวิศวกรระบบอัตโนมัติหลายคนคุ้นเคยกับสถานการณ์ที่ไม่มีใครทำการทดสอบที่พัฒนาขึ้นหรือใส่ใจในการบำรุงรักษายกเว้นคุณ เป็นผลให้การทดสอบล้าสมัยและคุณต้องใช้เวลาในการอัปเดต ขอย้ำอีกครั้งว่าในช่วงเริ่มต้นอาชีพ นี่อาจเป็นงานที่ค่อนข้างยาก: การตัดสินใจอย่างชาญฉลาดว่าเครื่องมือใดควรช่วยขจัดปัญหาที่กำหนด วิธีเลือก กำหนดค่า และบำรุงรักษาเครื่องมือเหล่านั้น ผู้ทดสอบบางคนหันไปขอความช่วยเหลือจาก DevOps (มนุษย์) และบอกตามตรงว่าแนวทางนี้ใช้ได้ผล ในหลายกรณี นี่อาจเป็นตัวเลือกเดียวเนื่องจากเราไม่สามารถมองเห็นการขึ้นต่อกันทั้งหมดได้ แต่ดังที่เราทราบ DevOps เป็นคนที่ยุ่งมาก เพราะพวกเขาต้องคิดถึงโครงสร้างพื้นฐานของบริษัททั้งหมด การใช้งาน การตรวจสอบ ไมโครเซอร์วิส และงานอื่น ๆ ที่คล้ายกัน ขึ้นอยู่กับองค์กร/ทีม ตามปกติแล้ว ระบบอัตโนมัติไม่ได้มีความสำคัญ ในกรณีเช่นนี้ เราต้องพยายามทำทุกอย่างเท่าที่เป็นไปได้ในส่วนของเราตั้งแต่ต้นจนจบ ซึ่งจะลดการพึ่งพา เร่งขั้นตอนการทำงาน พัฒนาทักษะของเรา และช่วยให้เราเห็นภาพที่ใหญ่ขึ้นของสิ่งที่เกิดขึ้น
บทความนี้นำเสนอเครื่องมือยอดนิยมและเป็นที่นิยมที่สุด และแสดงวิธีใช้เพื่อสร้างโครงสร้างพื้นฐานระบบอัตโนมัติทีละขั้นตอน แต่ละกลุ่มจะแสดงด้วยเครื่องมือที่ได้รับการทดสอบผ่านประสบการณ์ส่วนตัว แต่นั่นไม่ได้หมายความว่าคุณต้องใช้สิ่งเดียวกัน เครื่องมือนั้นไม่สำคัญ แต่ปรากฏและล้าสมัย งานวิศวกรรมของเราคือการเข้าใจหลักการพื้นฐาน: เหตุใดเราจึงต้องการเครื่องมือกลุ่มนี้ และปัญหาการทำงานใดบ้างที่เราสามารถแก้ไขได้ด้วยความช่วยเหลือ นั่นเป็นสาเหตุที่ในตอนท้ายของแต่ละส่วน ฉันจึงทิ้งลิงก์ไปยังเครื่องมือที่คล้ายกันที่อาจใช้ในองค์กรของคุณ
สิ่งที่ไม่มีอยู่ในบทความนี้
ฉันขอย้ำอีกครั้งว่าบทความนี้ไม่เกี่ยวกับเครื่องมือเฉพาะ ดังนั้นจะไม่มีการแทรกโค้ดจากเอกสารประกอบและคำอธิบายของคำสั่งเฉพาะ แต่ในตอนท้ายของแต่ละส่วนฉันจะทิ้งลิงก์ไว้เพื่อศึกษารายละเอียด
สิ่งนี้เสร็จสิ้นเพราะ:
- เนื้อหานี้หาได้ง่ายมากจากแหล่งต่างๆ (เอกสาร หนังสือ หลักสูตรวิดีโอ)
- ถ้าเราเริ่มเจาะลึกเราจะต้องเขียนบทความนี้ 10, 20, 30 ส่วน (ในขณะที่แผนคือ 2-3)
- ฉันไม่อยากเสียเวลาเพราะคุณอาจต้องการใช้เครื่องมืออื่นเพื่อให้บรรลุเป้าหมายเดียวกัน
การปฏิบัติ
ฉันอยากให้เนื้อหานี้มีประโยชน์กับผู้อ่านทุกคนจริงๆ ไม่ใช่แค่อ่านแล้วลืมไป ในการศึกษาใดๆ การฝึกฝนถือเป็นองค์ประกอบที่สำคัญมาก เพื่อสิ่งนี้ฉันได้เตรียมไว้แล้ว. นอกจากนี้ยังมีการบ้านรอคุณอยู่เพื่อให้แน่ใจว่าคุณจะไม่คัดลอกบรรทัดคำสั่งที่คุณกำลังดำเนินการโดยไม่ได้ตั้งใจ
แผนการ
ขั้นตอน
เทคโนโลยี
เครื่องมือ
1
การทำงานในพื้นที่ (เตรียมการทดสอบการสาธิตเว็บ / Android และเรียกใช้ในเครื่อง)
Node.js, ซีลีเนียม, Appium
2
ระบบควบคุมเวอร์ชัน
ไป
3
การทำตู้คอนเทนเนอร์
นักเทียบท่า, ตารางซีลีเนียม, Selenoid (เว็บ, Android)
4
ซีไอ/ซีดี
Gitlab CI
5
แพลตฟอร์ม Cloud
Google Cloud Platform
6
orchestration
Kubernetes
7
โครงสร้างพื้นฐานเป็นรหัส (IaC)
เทอร์ราฟอร์ม, แอนซิเบิ้ล
โครงสร้างของแต่ละส่วน
เพื่อให้การเล่าเรื่องมีความชัดเจน จึงอธิบายแต่ละส่วนตามโครงร่างต่อไปนี้:
- คำอธิบายสั้น ๆ ของเทคโนโลยี
- คุณค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
- ภาพประกอบสถานะปัจจุบันของโครงสร้างพื้นฐาน
- ลิงก์ไปยังการศึกษา
- เครื่องมือที่คล้ายกัน
1. รันการทดสอบในเครื่อง
คำอธิบายโดยย่อของเทคโนโลยี
นี่เป็นเพียงขั้นตอนการเตรียมการเพื่อเรียกใช้การทดสอบสาธิตในเครื่องและยืนยันว่าผ่านการทดสอบ ในทางปฏิบัตินั้น จะใช้ Node.js แต่ภาษาการเขียนโปรแกรมและแพลตฟอร์มก็ไม่สำคัญเช่นกัน และคุณสามารถใช้ภาษาและแพลตฟอร์มที่ใช้ในบริษัทของคุณได้
อย่างไรก็ตาม ในฐานะเครื่องมืออัตโนมัติ ฉันขอแนะนำให้ใช้ Selenium WebDriver สำหรับแพลตฟอร์มเว็บและ Appium สำหรับแพลตฟอร์ม Android ตามลำดับ เนื่องจากในขั้นตอนต่อไป เราจะใช้อิมเมจ Docker ที่ปรับแต่งให้ทำงานกับเครื่องมือเหล่านี้โดยเฉพาะ นอกจากนี้ เมื่อพิจารณาถึงความต้องการของงานแล้ว เครื่องมือเหล่านี้ยังเป็นที่ต้องการมากที่สุดในตลาด
ดังที่คุณอาจสังเกตเห็นแล้ว เราจะพิจารณาเฉพาะการทดสอบเว็บและ Android เท่านั้น น่าเสียดายที่ iOS เป็นเรื่องราวที่แตกต่างไปจากเดิมอย่างสิ้นเชิง (ขอบคุณ Apple) ฉันวางแผนที่จะนำเสนอโซลูชันและแนวทางปฏิบัติที่เกี่ยวข้องกับ IOS ในส่วนต่อๆ ไป
ความคุ้มค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
จากมุมมองของโครงสร้างพื้นฐาน การรันในเครื่องไม่ได้ให้คุณค่าใดๆ คุณตรวจสอบเฉพาะว่าการทดสอบทำงานบนเครื่องท้องถิ่นในเบราว์เซอร์และเครื่องจำลองในเครื่องเท่านั้น แต่ไม่ว่าในกรณีใด นี่เป็นจุดเริ่มต้นที่จำเป็น
ภาพประกอบสถานะปัจจุบันของโครงสร้างพื้นฐาน
ลิงค์เพื่อสำรวจ
เครื่องมือที่คล้ายกัน
- ภาษาการเขียนโปรแกรมใดๆ ที่คุณต้องการ ร่วมกับการทดสอบ Selenium/Appium
- การทดสอบใด ๆ
- นักวิ่งทดสอบคนใดก็ได้
2. ระบบควบคุมเวอร์ชัน (Git)
คำอธิบายโดยย่อของเทคโนโลยี
คงไม่ใช่เรื่องใหญ่สำหรับทุกคนหากฉันบอกว่าการควบคุมเวอร์ชันเป็นส่วนสำคัญอย่างยิ่งของการพัฒนา ทั้งในทีมและรายบุคคล จากแหล่งข้อมูลต่างๆ สามารถกล่าวได้ว่า Git เป็นตัวแทนที่ได้รับความนิยมมากที่สุด ระบบควบคุมเวอร์ชันให้ประโยชน์มากมาย เช่น การแชร์โค้ด การจัดเก็บเวอร์ชัน การกู้คืนไปยังสาขาก่อนหน้า การตรวจสอบประวัติโปรเจ็กต์ และการสำรองข้อมูล เราจะไม่พูดถึงแต่ละประเด็นโดยละเอียด เนื่องจากฉันแน่ใจว่าคุณคุ้นเคยกับมันเป็นอย่างดีและนำไปใช้ในการทำงานประจำวันของคุณ แต่ถ้าไม่กะทันหัน ฉันขอแนะนำให้หยุดอ่านบทความนี้และเติมช่องว่างนี้โดยเร็วที่สุด
ความคุ้มค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
และที่นี่คุณสามารถถามคำถามที่สมเหตุสมผล: “ทำไมเขาถึงบอกเราเกี่ยวกับ Git? ทุกคนรู้เรื่องนี้และใช้ทั้งสำหรับโค้ดการพัฒนาและโค้ดทดสอบอัตโนมัติ” คุณจะพูดถูกอย่างแน่นอน แต่ในบทความนี้ เรากำลังพูดถึงโครงสร้างพื้นฐาน และส่วนนี้ทำหน้าที่เป็นตัวอย่างสำหรับส่วนที่ 7: “โครงสร้างพื้นฐานเป็นโค้ด (IaC)” สำหรับเรา นี่หมายความว่าโครงสร้างพื้นฐานทั้งหมด รวมถึงการทดสอบ ได้รับการอธิบายไว้ในรูปแบบของโค้ด ดังนั้นเราจึงสามารถใช้ระบบการกำหนดเวอร์ชันกับโครงสร้างพื้นฐานดังกล่าว และรับประโยชน์ที่คล้ายกันสำหรับโค้ดการพัฒนาและการทำงานอัตโนมัติ
เราจะดูรายละเอียด IaC โดยละเอียดมากขึ้นในขั้นตอนที่ 7 แต่ถึงตอนนี้ คุณก็สามารถเริ่มใช้ Git ภายในเครื่องได้โดยการสร้างพื้นที่เก็บข้อมูลในเครื่อง ภาพใหญ่จะถูกขยายเมื่อเราเพิ่มพื้นที่เก็บข้อมูลระยะไกลให้กับโครงสร้างพื้นฐาน
ภาพประกอบสถานะปัจจุบันของโครงสร้างพื้นฐาน
ลิงค์เพื่อสำรวจ
เครื่องมือที่คล้ายกัน
3. การบรรจุ (นักเทียบท่า)
คำอธิบายโดยย่อของเทคโนโลยี
เพื่อแสดงให้เห็นว่าการบรรจุคอนเทนเนอร์ได้เปลี่ยนแปลงกฎของเกมอย่างไร เรามาย้อนเวลากลับไปสักสองสามทศวรรษกัน ในสมัยนั้น ผู้คนซื้อและใช้เครื่องเซิร์ฟเวอร์เพื่อรันแอปพลิเคชัน แต่ในกรณีส่วนใหญ่ ทรัพยากรเริ่มต้นที่จำเป็นไม่เป็นที่รู้จักล่วงหน้า เป็นผลให้บริษัทต่างๆ เสียเงินเพื่อซื้อเซิร์ฟเวอร์ราคาแพงและทรงพลัง แต่ความจุบางส่วนยังไม่ได้ใช้จนหมด
ขั้นต่อไปของวิวัฒนาการคือเครื่องเสมือน (VM) ซึ่งแก้ปัญหาการสิ้นเปลืองเงินกับทรัพยากรที่ไม่ได้ใช้ เทคโนโลยีนี้ทำให้สามารถรันแอปพลิเคชันแยกจากกันภายในเซิร์ฟเวอร์เดียวกันได้ โดยจัดสรรพื้นที่แยกกันโดยสิ้นเชิง แต่น่าเสียดายที่เทคโนโลยีใด ๆ ก็มีข้อเสีย การเรียกใช้ VM ต้องใช้ระบบปฏิบัติการเต็มรูปแบบ ซึ่งใช้ CPU, RAM, พื้นที่จัดเก็บข้อมูล และต้องคำนึงถึงต้นทุนสิทธิ์การใช้งาน ทั้งนี้ขึ้นอยู่กับระบบปฏิบัติการ ปัจจัยเหล่านี้ส่งผลต่อความเร็วในการโหลดและทำให้การพกพาทำได้ยาก
และตอนนี้เรามาถึงเรื่องการบรรจุตู้คอนเทนเนอร์ เป็นอีกครั้งที่เทคโนโลยีนี้แก้ไขปัญหาก่อนหน้านี้ เนื่องจากคอนเทนเนอร์ไม่ได้ใช้ระบบปฏิบัติการเต็มรูปแบบ ซึ่งทำให้มีทรัพยากรว่างจำนวนมาก และมอบโซลูชันที่รวดเร็วและยืดหยุ่นสำหรับการพกพา
แน่นอนว่าเทคโนโลยีการบรรจุหีบห่อไม่ใช่เรื่องใหม่และมีการเปิดตัวครั้งแรกในช่วงปลายทศวรรษที่ 70 ในสมัยนั้น มีการวิจัย การพัฒนา และความพยายามมากมาย แต่นักเทียบท่าเป็นผู้ปรับเทคโนโลยีนี้และทำให้คนทั่วไปเข้าถึงได้ง่าย ในปัจจุบันนี้ เมื่อเราพูดถึงคอนเทนเนอร์ โดยส่วนใหญ่แล้วเราหมายถึง Docker เมื่อเราพูดถึงคอนเทนเนอร์ Docker เราหมายถึงคอนเทนเนอร์ Linux เราสามารถใช้ระบบ Windows และ macOS เพื่อรันคอนเทนเนอร์ได้ แต่สิ่งสำคัญคือต้องเข้าใจว่าในกรณีนี้จะมีเลเยอร์เพิ่มเติมปรากฏขึ้น ตัวอย่างเช่น Docker บน Mac จะรันคอนเทนเนอร์ภายใน Linux VM แบบน้ำหนักเบาโดยไม่ต้องแจ้งให้ทราบ เราจะกลับมาที่หัวข้อนี้เมื่อเราหารือเกี่ยวกับการใช้งานโปรแกรมจำลอง Android ภายในคอนเทนเนอร์ ดังนั้นที่นี่มีความแตกต่างที่สำคัญมากที่ต้องพูดคุยในรายละเอียดเพิ่มเติม
ความคุ้มค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
เราพบว่าการบรรจุคอนเทนเนอร์และ Docker นั้นยอดเยี่ยม ลองดูสิ่งนี้ในบริบทของระบบอัตโนมัติ เนื่องจากเครื่องมือหรือเทคโนโลยีทุกอย่างจำเป็นต้องแก้ปัญหา ให้เราสรุปปัญหาที่ชัดเจนของการทดสอบอัตโนมัติในบริบทของการทดสอบ UI:
- การพึ่งพาจำนวนมากเมื่อติดตั้ง Selenium และโดยเฉพาะ Appium
- ปัญหาความเข้ากันได้ระหว่างเวอร์ชันของเบราว์เซอร์ เครื่องจำลอง และไดรเวอร์
- ขาดพื้นที่แยกสำหรับเบราว์เซอร์/เครื่องจำลอง ซึ่งมีความสำคัญอย่างยิ่งสำหรับการทำงานแบบขนาน
- ยากต่อการจัดการและบำรุงรักษาหากคุณต้องการใช้งานเบราว์เซอร์ 10, 50, 100 หรือ 1000 ตัวในเวลาเดียวกัน
แต่เนื่องจาก Selenium เป็นเครื่องมืออัตโนมัติที่ได้รับความนิยมมากที่สุด และ Docker เป็นเครื่องมือคอนเทนเนอร์ที่ได้รับความนิยมมากที่สุด จึงไม่น่าแปลกใจเลยที่จะมีใครบางคนพยายามรวมพวกมันเข้าด้วยกันเพื่อสร้างเครื่องมือที่ทรงพลังในการแก้ปัญหาที่กล่าวมาข้างต้น ลองพิจารณาวิธีแก้ปัญหาดังกล่าวโดยละเอียด
ตารางซีลีเนียมในนักเทียบท่า
เครื่องมือนี้ได้รับความนิยมมากที่สุดในโลก Selenium สำหรับการเรียกใช้เบราว์เซอร์หลายตัวบนเครื่องหลายเครื่องและจัดการเบราว์เซอร์จากศูนย์กลาง ในการเริ่มต้น คุณต้องลงทะเบียนอย่างน้อย 2 ส่วน: ฮับและโหนด Hub เป็นโหนดกลางที่รับคำขอทั้งหมดจากการทดสอบและกระจายไปยังโหนดที่เหมาะสม สำหรับแต่ละโหนด เราสามารถกำหนดค่าการกำหนดค่าเฉพาะได้ เช่น โดยการระบุเบราว์เซอร์และเวอร์ชันที่ต้องการ อย่างไรก็ตาม เรายังต้องดูแลไดรเวอร์เบราว์เซอร์ที่เข้ากันได้ด้วยตัวเอง และติดตั้งไดรเวอร์เหล่านั้นบนโหนดที่ต้องการ ด้วยเหตุผลนี้ ตารางซีลีเนียมจึงไม่ได้ใช้ในรูปแบบบริสุทธิ์ ยกเว้นเมื่อเราต้องการทำงานกับเบราว์เซอร์ที่ไม่สามารถติดตั้งบน Linux OS สำหรับกรณีอื่นๆ ทั้งหมด วิธีแก้ปัญหาที่ยืดหยุ่นและถูกต้องอย่างมากคือการใช้อิมเมจ Docker เพื่อรัน Selenium grid Hub และ Nodes วิธีการนี้ทำให้การจัดการโหนดง่ายขึ้นอย่างมาก เนื่องจากเราสามารถเลือกอิมเมจที่เราต้องการด้วยเบราว์เซอร์และไดรเวอร์เวอร์ชันที่เข้ากันได้ที่ติดตั้งไว้แล้ว
แม้จะมีบทวิจารณ์เชิงลบเกี่ยวกับความเสถียร โดยเฉพาะอย่างยิ่งเมื่อรันโหนดจำนวนมากพร้อมกัน ตารางซีลีเนียมยังคงเป็นเครื่องมือยอดนิยมที่สุดสำหรับการรันการทดสอบซีลีเนียมแบบขนาน สิ่งสำคัญคือต้องทราบว่าการปรับปรุงและแก้ไขเครื่องมือนี้จะปรากฏอย่างต่อเนื่องในโอเพ่นซอร์ส ซึ่งต่อสู้กับปัญหาคอขวดต่างๆ
Selenoid สำหรับเว็บ
เครื่องมือนี้เป็นความก้าวหน้าในโลกของ Selenium เนื่องจากทำงานได้ทันทีที่แกะกล่อง และทำให้ชีวิตของวิศวกรระบบอัตโนมัติหลายคนง่ายขึ้นมาก ก่อนอื่น นี่ไม่ใช่การดัดแปลงตารางซีลีเนียมอีก นักพัฒนาได้สร้าง Selenium Hub เวอร์ชันใหม่ทั้งหมดใน Golang ซึ่งเมื่อรวมกับอิมเมจ Docker ที่มีน้ำหนักเบาสำหรับเบราว์เซอร์ต่างๆ ทำให้เกิดแรงผลักดันในการพัฒนาระบบทดสอบอัตโนมัติ ยิ่งไปกว่านั้น ในกรณีของ Selenium Grid เราต้องกำหนดเบราว์เซอร์ที่จำเป็นทั้งหมดและเวอร์ชันล่วงหน้า ซึ่งไม่เป็นปัญหาเมื่อทำงานกับเบราว์เซอร์เดียว แต่เมื่อพูดถึงเบราว์เซอร์ที่รองรับหลายตัว Selenoid ถือเป็นโซลูชั่นอันดับหนึ่งด้วยคุณสมบัติ 'เบราว์เซอร์ตามความต้องการ' สิ่งที่เราจำเป็นต้องมีคือการดาวน์โหลดรูปภาพที่จำเป็นด้วยเบราว์เซอร์ล่วงหน้าและอัปเดตไฟล์การกำหนดค่าที่ Selenoid โต้ตอบ หลังจากที่ Selenoid ได้รับคำขอจากการทดสอบแล้ว มันก็จะเปิดคอนเทนเนอร์ที่ต้องการด้วยเบราว์เซอร์ที่ต้องการโดยอัตโนมัติ เมื่อการทดสอบเสร็จสิ้น Selenoid จะเลิกใช้คอนเทนเนอร์ ซึ่งจะทำให้มีทรัพยากรว่างมากขึ้นสำหรับการร้องขอในอนาคต วิธีการนี้ช่วยขจัดปัญหาที่รู้จักกันดีของ 'การเสื่อมของโหนด' ที่เรามักพบในตารางซีลีเนียมอย่างสมบูรณ์
แต่อนิจจา Selenoid ยังไม่ใช่กระสุนเงิน เราได้รับฟีเจอร์ 'เบราว์เซอร์ตามความต้องการ' แต่ฟีเจอร์ 'ทรัพยากรตามความต้องการ' ยังไม่สามารถใช้งานได้ หากต้องการใช้ Selenoid เราต้องปรับใช้บนฮาร์ดแวร์กายภาพหรือบน VM ซึ่งหมายความว่าเราต้องทราบล่วงหน้าว่าต้องจัดสรรทรัพยากรจำนวนเท่าใด ฉันเดาว่านี่ไม่ใช่ปัญหาสำหรับโปรเจ็กต์ขนาดเล็กที่ใช้เบราว์เซอร์ 10, 20 หรือ 30 ตัวพร้อมกัน แต่ถ้าเราต้องการ 100, 500, 1000 ขึ้นไปล่ะ? มันไม่สมเหตุสมผลเลยที่จะรักษาและจ่ายเงินสำหรับทรัพยากรจำนวนมากตลอดเวลา ในส่วนที่ 5 และ 6 ของบทความนี้ เราจะพูดถึงโซลูชันที่ช่วยให้คุณสามารถขยายขนาดได้ ซึ่งจะช่วยลดต้นทุนของบริษัทได้อย่างมาก
เซลีนอยด์สำหรับ Android
หลังจากความสำเร็จของ Selenoid ในฐานะเครื่องมืออัตโนมัติบนเว็บ ผู้คนก็ต้องการสิ่งที่คล้ายกันสำหรับ Android และมันก็เกิดขึ้น - Selenoid เปิดตัวพร้อมรองรับ Android จากมุมมองของผู้ใช้ระดับสูง หลักการทำงานคล้ายกับระบบอัตโนมัติของเว็บ ข้อแตกต่างเพียงอย่างเดียวคือ Selenoid รันคอนเทนเนอร์จำลอง Android แทนที่จะเป็นคอนเทนเนอร์ของเบราว์เซอร์ ในความคิดของฉัน ปัจจุบันนี้เป็นเครื่องมือฟรีที่ทรงพลังที่สุดสำหรับการทดสอบ Android แบบขนาน
ฉันไม่อยากพูดถึงด้านลบของเครื่องมือนี้จริงๆ เนื่องจากฉันชอบมันมาก แต่ยังคงมีข้อเสียแบบเดียวกันที่ใช้กับระบบอัตโนมัติของเว็บและเกี่ยวข้องกับการปรับขนาด นอกจากนี้ เราต้องพูดถึงข้อจำกัดอีกประการหนึ่งที่อาจเป็นเรื่องที่น่าแปลกใจหากเราตั้งค่าเครื่องมือเป็นครั้งแรก หากต้องการเรียกใช้อิมเมจ Android เราจำเป็นต้องมีเครื่องจริงหรือ VM ที่รองรับการจำลองเสมือนแบบซ้อน ในคำแนะนำวิธีการ ฉันสาธิตวิธีเปิดใช้งานสิ่งนี้บน Linux VM อย่างไรก็ตาม หากคุณเป็นผู้ใช้ macOS และต้องการปรับใช้ Selenoid ภายในเครื่อง คุณจะไม่สามารถเรียกใช้การทดสอบ Android ได้ แต่คุณสามารถเรียกใช้ Linux VM ภายในเครื่องได้ตลอดเวลาโดยกำหนดค่า 'การจำลองเสมือนแบบซ้อน' และปรับใช้ Selenoid ภายใน
ภาพประกอบสถานะปัจจุบันของโครงสร้างพื้นฐาน
ในบริบทของบทความนี้ เราจะเพิ่มเครื่องมือ 2 รายการเพื่อแสดงโครงสร้างพื้นฐาน เหล่านี้คือตาราง Selenium สำหรับการทดสอบเว็บและ Selenoid สำหรับการทดสอบ Android ในบทช่วยสอน GitHub ฉันจะแสดงให้คุณเห็นถึงวิธีใช้ Selenoid เพื่อรันการทดสอบเว็บ
ลิงค์เพื่อสำรวจ
เครื่องมือที่คล้ายกัน
- มีเครื่องมือคอนเทนเนอร์อื่น ๆ แต่ Docker ได้รับความนิยมมากที่สุด หากคุณต้องการลองอย่างอื่น โปรดจำไว้ว่าเครื่องมือที่เราได้กล่าวถึงสำหรับการรันการทดสอบ Selenium พร้อมกันนั้นจะใช้งานไม่ได้ตั้งแต่แกะกล่อง
- ดังที่ได้กล่าวไปแล้ว มีการดัดแปลงตาราง Selenium มากมาย เช่น.
4.CI/ซีดี
คำอธิบายโดยย่อของเทคโนโลยี
การบูรณาการอย่างต่อเนื่องค่อนข้างเป็นที่นิยมในการพัฒนาและทัดเทียมกับระบบควบคุมเวอร์ชัน อย่างไรก็ตาม ฉันรู้สึกว่ามีความสับสนในคำศัพท์ ในย่อหน้านี้ฉันต้องการอธิบายการปรับเปลี่ยนเทคโนโลยีนี้ 3 รายการจากมุมมองของฉัน บนอินเทอร์เน็ต คุณจะพบบทความมากมายที่มีการตีความต่างกัน และถือเป็นเรื่องปกติหากความคิดเห็นของคุณแตกต่างออกไป สิ่งที่สำคัญที่สุดคือคุณเข้าใจตรงกันกับเพื่อนร่วมงาน
ดังนั้นจึงมี 3 คำ: CI - การบูรณาการอย่างต่อเนื่อง, CD - การจัดส่งอย่างต่อเนื่อง และอีกครั้ง CD - การปรับใช้อย่างต่อเนื่อง (ด้านล่างนี้ฉันจะใช้คำเหล่านี้เป็นภาษาอังกฤษ). การปรับเปลี่ยนแต่ละครั้งจะเพิ่มขั้นตอนเพิ่มเติมหลายขั้นตอนให้กับไปป์ไลน์การพัฒนาของคุณ แต่คำว่า ต่อเนื่องกัน (ต่อเนื่อง) คือสิ่งที่สำคัญที่สุด ในบริบทนี้ เราหมายถึงสิ่งที่เกิดขึ้นตั้งแต่ต้นจนจบ โดยไม่มีการหยุดชะงักหรือการแทรกแซงด้วยตนเอง ลองดูที่ CI & CD และ CD ในบริบทนี้
- การบูรณาการอย่างต่อเนื่อง นี่เป็นก้าวเริ่มต้นของวิวัฒนาการ หลังจากส่งรหัสใหม่ไปยังเซิร์ฟเวอร์ เราคาดว่าจะได้รับการตอบกลับอย่างรวดเร็วว่าการเปลี่ยนแปลงของเราใช้ได้ โดยทั่วไป CI ประกอบด้วยการเรียกใช้เครื่องมือวิเคราะห์โค้ดแบบคงที่และการทดสอบ API ของหน่วย/ภายใน ซึ่งช่วยให้เรารับข้อมูลเกี่ยวกับโค้ดของเราได้ภายในไม่กี่วินาที/นาที
- การจัดส่งแบบต่อเนื่อง เป็นขั้นตอนขั้นสูงกว่าที่เราดำเนินการทดสอบการรวม/UI อย่างไรก็ตาม ในขั้นตอนนี้ เราไม่ได้รับผลลัพธ์เร็วเท่ากับ CI ประการแรก การทดสอบประเภทนี้ใช้เวลานานกว่าจึงจะเสร็จสมบูรณ์ ประการที่สอง ก่อนที่จะเปิดตัว เราต้องปรับใช้การเปลี่ยนแปลงของเรากับสภาพแวดล้อมการทดสอบ/การแสดงชั่วคราว ยิ่งไปกว่านั้น หากเรากำลังพูดถึงการพัฒนาอุปกรณ์เคลื่อนที่ ขั้นตอนเพิ่มเติมจะปรากฏขึ้นเพื่อสร้างบิลด์ของแอปพลิเคชันของเรา
- การปรับใช้อย่างต่อเนื่อง ถือว่าเราจะเผยแพร่การเปลี่ยนแปลงการผลิตโดยอัตโนมัติหากผ่านการทดสอบการยอมรับทั้งหมดในขั้นตอนก่อนหน้า นอกจากนี้ หลังจากระยะการเปิดตัว คุณสามารถกำหนดค่าระยะต่างๆ ได้ เช่น การรันการทดสอบควันในการใช้งานจริง และการรวบรวมเมทริกที่สนใจ การปรับใช้อย่างต่อเนื่องสามารถทำได้โดยมีความครอบคลุมที่ดีโดยการทดสอบอัตโนมัติเท่านั้น หากจำเป็นต้องมีการแทรกแซงด้วยตนเอง รวมถึงการทดสอบ การดำเนินการนี้จะไม่อีกต่อไป อย่างต่อเนื่อง (ต่อเนื่อง). จากนั้นเราสามารถพูดได้ว่าไปป์ไลน์ของเราปฏิบัติตามแนวทางปฏิบัติในการจัดส่งแบบต่อเนื่องเท่านั้น
ความคุ้มค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
ในส่วนนี้ ฉันควรชี้แจงว่าเมื่อเราพูดถึงการทดสอบ UI แบบ end-to-end หมายความว่าเราควรปรับใช้การเปลี่ยนแปลงและบริการที่เกี่ยวข้องเพื่อทดสอบสภาพแวดล้อม การบูรณาการอย่างต่อเนื่อง - กระบวนการนี้ใช้ไม่ได้กับงานนี้ และเราต้องดูแลการนำแนวทางปฏิบัติในการส่งมอบอย่างต่อเนื่องเป็นอย่างน้อย การปรับใช้อย่างต่อเนื่องยังสมเหตุสมผลในบริบทของการทดสอบ UI หากเราจะใช้งานจริง
และก่อนที่เราจะดูภาพประกอบของการเปลี่ยนแปลงทางสถาปัตยกรรม ฉันอยากจะพูดสักสองสามคำเกี่ยวกับ GitLab CI ไม่เหมือนกับเครื่องมือ CI/CD อื่นๆ GitLab มีพื้นที่เก็บข้อมูลระยะไกลและคุณลักษณะเพิ่มเติมอื่นๆ อีกมากมาย ดังนั้น GitLab จึงเป็นมากกว่า CI ประกอบด้วยการจัดการซอร์สโค้ด การจัดการแบบ Agile ไปป์ไลน์ CI/CD เครื่องมือบันทึก และการรวบรวมตัวชี้วัดทันที สถาปัตยกรรม GitLab ประกอบด้วย Gitlab CI/CD และ GitLab Runner นี่คือคำอธิบายสั้น ๆ จากเว็บไซต์อย่างเป็นทางการ:
Gitlab CI/CD เป็นเว็บแอปพลิเคชันที่มี API ที่เก็บสถานะไว้ในฐานข้อมูล จัดการโปรเจ็กต์/บิลด์ และจัดเตรียมอินเทอร์เฟซผู้ใช้ GitLab Runner เป็นแอปพลิเคชันที่ประมวลผลการสร้าง สามารถใช้งานแยกกันและทำงานร่วมกับ GitLab CI/CD ผ่านทาง API สำหรับการทดสอบที่ทำงานอยู่ คุณต้องมีทั้งอินสแตนซ์ Gitlab และ Runner
ภาพประกอบสถานะปัจจุบันของโครงสร้างพื้นฐาน
ลิงค์เพื่อสำรวจ
เครื่องมือที่คล้ายกัน
- และอื่น ๆ อีกมากมาย
5. แพลตฟอร์มคลาวด์
คำอธิบายโดยย่อของเทคโนโลยี
ในส่วนนี้เราจะพูดถึงเทรนด์ยอดนิยมที่เรียกว่า 'คลาวด์สาธารณะ' แม้ว่าเทคโนโลยีเวอร์ช่วลไลเซชั่นและคอนเทนเนอร์ไลเซชั่นที่อธิบายไว้ข้างต้นจะให้ประโยชน์มหาศาล แต่เรายังคงต้องการทรัพยากรการประมวลผล บริษัทต่างๆ ซื้อเซิร์ฟเวอร์ราคาแพงหรือเช่าศูนย์ข้อมูล แต่ในกรณีนี้ จำเป็นต้องคำนวณ (บางครั้งก็ไม่สมจริง) ว่าเราต้องการทรัพยากรจำนวนเท่าใด ไม่ว่าเราจะใช้งานทุกวันตลอด 24 ชั่วโมงหรือไม่ก็ตาม และเพื่อวัตถุประสงค์อะไร ตัวอย่างเช่น การผลิตต้องใช้เซิร์ฟเวอร์ที่ทำงานตลอด 7 ชั่วโมงทุกวัน แต่เราจำเป็นต้องมีทรัพยากรที่คล้ายกันสำหรับการทดสอบนอกเวลาทำงานหรือไม่ นอกจากนี้ยังขึ้นอยู่กับประเภทของการทดสอบที่ดำเนินการด้วย ตัวอย่างคือการทดสอบภาระ/ความเครียดที่เราวางแผนจะดำเนินการในช่วงเวลานอกเวลาทำงานเพื่อให้ได้ผลลัพธ์ในวันถัดไป แต่แน่นอนว่าไม่จำเป็นต้องมีความพร้อมใช้งานของเซิร์ฟเวอร์ตลอด XNUMX ชั่วโมงทุกวันสำหรับการทดสอบอัตโนมัติแบบ end-to-end และโดยเฉพาะอย่างยิ่งไม่รวมถึงสภาพแวดล้อมการทดสอบด้วยตนเอง สำหรับสถานการณ์ดังกล่าว เป็นการดีที่จะได้รับทรัพยากรให้มากเท่าที่จำเป็นตามความต้องการ ใช้ทรัพยากรเหล่านั้น และหยุดจ่ายเงินเมื่อไม่จำเป็นต้องใช้อีกต่อไป ยิ่งไปกว่านั้น เป็นการดีที่จะได้รับทันทีด้วยการคลิกเมาส์ไม่กี่ครั้งหรือเรียกใช้สคริปต์สองสามตัว นี่คือสิ่งที่ระบบคลาวด์สาธารณะใช้สำหรับ ลองดูคำจำกัดความ:
“คลาวด์สาธารณะถูกกำหนดให้เป็นบริการคอมพิวเตอร์ที่นำเสนอโดยผู้ให้บริการบุคคลที่สามผ่านอินเทอร์เน็ตสาธารณะ ทำให้ทุกคนที่ต้องการใช้หรือซื้อสามารถเข้าถึงได้ มันอาจจะฟรีหรือขายตามความต้องการ ทำให้ลูกค้าจ่ายเฉพาะการใช้งานรอบ CPU พื้นที่เก็บข้อมูล หรือแบนด์วิดท์ที่พวกเขาใช้เท่านั้น"
มีความเห็นว่าคลาวด์สาธารณะมีราคาแพง แต่แนวคิดหลักของพวกเขาคือการลดต้นทุนของบริษัท ตามที่กล่าวไว้ข้างต้น คลาวด์สาธารณะช่วยให้คุณได้รับทรัพยากรตามความต้องการและจ่ายเฉพาะเวลาที่คุณใช้เท่านั้น นอกจากนี้ บางครั้งเราลืมไปว่าพนักงานได้รับเงินเดือน และผู้เชี่ยวชาญก็เป็นทรัพยากรที่มีราคาแพงเช่นกัน ต้องคำนึงว่าระบบคลาวด์สาธารณะทำให้การสนับสนุนโครงสร้างพื้นฐานง่ายขึ้นมาก ซึ่งช่วยให้วิศวกรสามารถมุ่งเน้นไปที่งานที่สำคัญกว่าได้
ความคุ้มค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
เราต้องใช้ทรัพยากรเฉพาะอะไรบ้างสำหรับการทดสอบ UI แบบ end-to-end โดยพื้นฐานแล้วสิ่งเหล่านี้คือเครื่องเสมือนหรือคลัสเตอร์ (เราจะพูดถึง Kubernetes ในหัวข้อถัดไป) สำหรับการเรียกใช้เบราว์เซอร์และโปรแกรมจำลอง ยิ่งเราต้องการใช้เบราว์เซอร์และอีมูเลเตอร์พร้อมกันมากเท่าไร ก็ยิ่งต้องใช้ CPU และหน่วยความจำมากขึ้นเท่านั้น และเราต้องเสียเงินซื้อมันมากขึ้นด้วย ดังนั้น คลาวด์สาธารณะในบริบทของการทดสอบอัตโนมัติทำให้เราสามารถรันเบราว์เซอร์/อีมูเลเตอร์จำนวนมาก (100, 200, 1000...) ตามความต้องการ รับผลการทดสอบโดยเร็วที่สุด และหยุดจ่ายเงินสำหรับการใช้ทรัพยากรอย่างบ้าคลั่งเช่นนี้ พลัง.
ผู้ให้บริการคลาวด์ที่ได้รับความนิยมมากที่สุด ได้แก่ Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) คู่มือวิธีใช้จะมีตัวอย่างวิธีใช้ GCP แต่โดยทั่วไปแล้ว ไม่สำคัญว่าคุณจะใช้อะไรสำหรับงานอัตโนมัติ พวกเขาทั้งหมดมีฟังก์ชันการทำงานที่เหมือนกันโดยประมาณ โดยทั่วไปแล้ว ในการเลือกผู้ให้บริการ ฝ่ายบริหารจะมุ่งเน้นไปที่โครงสร้างพื้นฐานโดยรวมของบริษัทและข้อกำหนดทางธุรกิจ ซึ่งอยู่นอกเหนือขอบเขตของบทความนี้ สำหรับวิศวกรระบบอัตโนมัติ การเปรียบเทียบการใช้ผู้ให้บริการคลาวด์กับการใช้แพลตฟอร์มคลาวด์เพื่อการทดสอบโดยเฉพาะ เช่น Sauce Labs, BrowserStack, BitBar และอื่นๆ จะน่าสนใจกว่า งั้นก็ทำเหมือนกัน! ในความคิดของฉัน Sauce Labs เป็นฟาร์มทดสอบคลาวด์ที่มีชื่อเสียงที่สุด ซึ่งเป็นเหตุผลว่าทำไมฉันถึงใช้มันเพื่อเปรียบเทียบ
GCP กับ Sauce Labs เพื่อวัตถุประสงค์ด้านระบบอัตโนมัติ:
ลองจินตนาการว่าเราต้องทำการทดสอบเว็บ 8 รายการและการทดสอบ Android 8 รายการพร้อมกัน สำหรับสิ่งนี้ เราจะใช้ GCP และรันเครื่องเสมือน 2 เครื่องด้วย Selenoid ในตอนแรกเราจะยก 8 คอนเทนเนอร์พร้อมเบราว์เซอร์ ประการที่สองมี 8 คอนเทนเนอร์พร้อมอีมูเลเตอร์ มาดูราคากัน:
เราต้องการหนึ่งคอนเทนเนอร์ด้วย Chrome n1-มาตรฐาน-1 รถ. ในกรณีของ Android มันจะเป็น n1-มาตรฐาน-4 สำหรับโปรแกรมจำลองหนึ่งเครื่อง ในความเป็นจริง วิธีที่ยืดหยุ่นกว่าและราคาถูกกว่าคือการตั้งค่าผู้ใช้เฉพาะสำหรับ CPU/หน่วยความจำ แต่ในขณะนี้ การเปรียบเทียบกับ Sauce Labs ไม่สำคัญ
และนี่คืออัตราภาษีสำหรับการใช้ Sauce Labs:
ฉันเชื่อว่าคุณสังเกตเห็นความแตกต่างแล้ว แต่ฉันจะยังคงจัดทำตารางการคำนวณสำหรับงานของเรา:
ทรัพยากรที่จำเป็น
รายเดือน
ชั่วโมงทำงาน(8 – 8 น.)
ชั่วโมงทำงาน+ ยอมเสียก่อน
GCP สำหรับเว็บ
n1-มาตรฐาน-1 x 8 = n1-มาตรฐาน-8
$194.18
23 วัน * 12 ชม. * 0.38 = 104.88 ดอลลาร์
23 วัน * 12 ชม. * 0.08 = 22.08 ดอลลาร์
Sauce Labs สำหรับเว็บ
การทดสอบแบบขนาน Virtual Cloud8
$1.559
-
-
GCP สำหรับ Android
n1-มาตรฐาน-4 x 8: n1-มาตรฐาน-16
$776.72
23 วัน * 12 ชม. * 1.52 = 419.52 ดอลลาร์
23 วัน * 12 ชม. * 0.32 = 88.32 ดอลลาร์
ซอสแล็บสำหรับ Android
การทดสอบแบบขนาน Real Device Cloud 8
$1.999
-
-
อย่างที่คุณเห็น ต้นทุนที่แตกต่างกันมีมาก โดยเฉพาะอย่างยิ่งหากคุณทำการทดสอบเฉพาะในช่วงเวลาทำงานสิบสองชั่วโมงเท่านั้น แต่คุณสามารถลดต้นทุนได้มากขึ้นไปอีกหากคุณใช้เครื่องจักรที่ยอมให้มีการขัดจังหวะชั่วคราว มันคืออะไร?
VM ที่ยอมให้มีการขัดจังหวะชั่วคราวเป็นอินสแตนซ์ที่คุณสามารถสร้างและเรียกใช้ได้ในราคาที่ต่ำกว่าอินสแตนซ์ปกติมาก อย่างไรก็ตาม Compute Engine อาจยุติ (จองล่วงหน้า) อินสแตนซ์เหล่านี้ หากต้องการเข้าถึงทรัพยากรเหล่านั้นสำหรับงานอื่นๆ อินสแตนซ์ที่ยอมให้มีการขัดจังหวะชั่วคราวคือความจุส่วนเกินของ Compute Engine ดังนั้นความพร้อมใช้งานจึงแตกต่างกันไปตามการใช้งาน
หากแอปของคุณทนทานต่อข้อผิดพลาดและสามารถทนต่อการขออินสแตนซ์ที่เป็นไปได้ อินสแตนซ์ที่ยอมให้มีการขัดจังหวะชั่วคราวสามารถลดต้นทุน Compute Engine ของคุณได้อย่างมาก ตัวอย่างเช่น งานการประมวลผลเป็นชุดสามารถทำงานบนอินสแตนซ์ที่ยอมให้มีการขัดจังหวะชั่วคราวได้ หากบางอินสแตนซ์สิ้นสุดลงในระหว่างการประมวลผล งานจะช้าลงแต่ไม่ได้หยุดโดยสิ้นเชิง อินสแตนซ์ที่ยอมให้มีการขัดจังหวะชั่วคราวจะทำให้งานการประมวลผลเป็นชุดของคุณเสร็จสมบูรณ์โดยไม่ต้องวางภาระงานเพิ่มเติมบนอินสแตนซ์ที่มีอยู่ และโดยที่คุณไม่ต้องจ่ายเงินเต็มจำนวนสำหรับอินสแตนซ์ปกติเพิ่มเติม
และมันยังไม่จบ! ในความเป็นจริง ฉันแน่ใจว่าไม่มีใครทำการทดสอบเป็นเวลา 12 ชั่วโมงโดยไม่หยุดพัก และหากเป็นเช่นนั้น คุณก็จะสามารถเริ่มและหยุดเครื่องเสมือนได้โดยอัตโนมัติเมื่อไม่จำเป็น เวลาใช้งานจริงอาจลดลงเหลือ 6 ชั่วโมงต่อวัน จากนั้นการชำระเงินในบริบทของงานของเราจะลดลงเหลือ $11 ต่อเดือนสำหรับ 8 เบราว์เซอร์ มันไม่วิเศษเหรอ? แต่ด้วยเครื่องจักรที่ยอมให้มีการขัดจังหวะชั่วคราว เราจะต้องระมัดระวังและเตรียมพร้อมสำหรับการหยุดชะงักและความไม่เสถียร แม้ว่าสถานการณ์เหล่านี้สามารถจัดเตรียมและจัดการได้ในซอฟต์แวร์ก็ตาม มันคุ้มค่า!
แต่ฉันไม่ได้หมายความว่า 'อย่าใช้ฟาร์มทดสอบระบบคลาวด์' พวกเขามีข้อดีหลายประการ ก่อนอื่น นี่ไม่ใช่แค่เครื่องเสมือน แต่เป็นโซลูชันการทดสอบอัตโนมัติเต็มรูปแบบพร้อมชุดฟังก์ชันการทำงานที่พร้อมใช้งานทันที: การเข้าถึงระยะไกล บันทึก ภาพหน้าจอ การบันทึกวิดีโอ เบราว์เซอร์ต่างๆ และอุปกรณ์เคลื่อนที่จริง ในหลาย ๆ สถานการณ์ สิ่งนี้อาจเป็นทางเลือกสุดชิคที่จำเป็น แพลตฟอร์มการทดสอบมีประโยชน์อย่างยิ่งสำหรับระบบอัตโนมัติของ IOS เมื่อคลาวด์สาธารณะให้บริการได้เฉพาะระบบ Linux/Windows เท่านั้น แต่เราจะพูดถึง iOS ในบทความต่อไปนี้ ฉันแนะนำให้พิจารณาสถานการณ์และเริ่มจากงานอยู่เสมอ ในบางกรณี การใช้คลาวด์สาธารณะจะถูกกว่าและมีประสิทธิภาพมากกว่า และในบางกรณี แพลตฟอร์มทดสอบก็คุ้มค่ากับเงินที่เสียไปอย่างแน่นอน
ภาพประกอบสถานะปัจจุบันของโครงสร้างพื้นฐาน
ลิงค์เพื่อสำรวจ
เครื่องมือที่คล้ายกัน:
6. การเรียบเรียง
คำอธิบายโดยย่อของเทคโนโลยี
ฉันมีข่าวดี - เราเกือบจะอยู่ท้ายบทความแล้ว! ในขณะนี้ โครงสร้างพื้นฐานอัตโนมัติของเราประกอบด้วยการทดสอบเว็บและ Android ซึ่งเราดำเนินการผ่าน GitLab CI แบบคู่ขนาน โดยใช้เครื่องมือที่เปิดใช้งาน Docker: ตาราง Selenium และ Selenoid นอกจากนี้ เรายังใช้เครื่องเสมือนที่สร้างผ่าน GCP เพื่อโฮสต์คอนเทนเนอร์ด้วยเบราว์เซอร์และโปรแกรมจำลอง เพื่อลดต้นทุน เราจะเริ่มเครื่องเสมือนเหล่านี้ตามความต้องการเท่านั้น และหยุดเมื่อไม่ได้ทำการทดสอบ มีอะไรอีกบ้างที่สามารถปรับปรุงโครงสร้างพื้นฐานของเราได้? คำตอบคือใช่! พบกับ Kubernetes (K8s)!
ก่อนอื่น เรามาดูกันว่าคำว่า orchestration,คลัสเตอร์ และ Kubernetes มีความสัมพันธ์กันอย่างไร ในระดับสูง การประสานคือระบบที่ปรับใช้และจัดการแอปพลิเคชัน สำหรับการทดสอบอัตโนมัติ แอปพลิเคชันในคอนเทนเนอร์ดังกล่าว ได้แก่ ตารางซีลีเนียมและซีลีนอยด์ Docker และ K8s ส่งเสริมซึ่งกันและกัน อันแรกใช้สำหรับการปรับใช้แอปพลิเคชัน ส่วนอันที่สองสำหรับการประสาน ในทางกลับกัน K8s จะเป็นคลัสเตอร์ งานของคลัสเตอร์คือการใช้ VM เป็นโหนด ซึ่งช่วยให้คุณสามารถติดตั้งฟังก์ชันการทำงาน โปรแกรม และบริการต่างๆ ภายในเซิร์ฟเวอร์เดียว (คลัสเตอร์) หากโหนดใดล้มเหลว โหนดอื่นจะเริ่มทำงาน ซึ่งทำให้แอปพลิเคชันของเราทำงานได้อย่างต่อเนื่อง นอกจากนี้ K8 ยังมีฟังก์ชันการทำงานที่สำคัญที่เกี่ยวข้องกับการปรับขนาด ซึ่งช่วยให้เราได้รับทรัพยากรในปริมาณที่เหมาะสมที่สุดโดยอัตโนมัติตามปริมาณงานและขีดจำกัดที่ตั้งไว้
ที่จริงแล้ว การปรับใช้ Kubernetes ตั้งแต่เริ่มต้นด้วยตนเองไม่ใช่เรื่องเล็กน้อยเลย ฉันจะทิ้งลิงก์ไปยังคำแนะนำวิธีการที่มีชื่อเสียง "Kubernetes The Hard Way" และหากคุณสนใจ ก็สามารถฝึกฝนได้ แต่โชคดีที่มีวิธีการและเครื่องมือทางเลือกอื่น วิธีที่ง่ายที่สุดคือใช้ Google Kubernetes Engine (GKE) ใน GCP ซึ่งจะช่วยให้คุณได้รับคลัสเตอร์สำเร็จรูปได้ในไม่กี่คลิก ฉันขอแนะนำให้ใช้วิธีนี้เพื่อเริ่มเรียนรู้ เนื่องจากจะช่วยให้คุณมุ่งเน้นไปที่การเรียนรู้วิธีใช้ K8 สำหรับงานของคุณ แทนที่จะเรียนรู้ว่าส่วนประกอบภายในควรบูรณาการเข้าด้วยกันอย่างไร
ความคุ้มค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
มาดูคุณสมบัติสำคัญบางประการที่ K8 มีให้:
- การปรับใช้แอปพลิเคชัน: การใช้คลัสเตอร์หลายโหนดแทน VM
- การปรับขนาดแบบไดนามิก: ลดต้นทุนทรัพยากรที่ใช้ตามความต้องการเท่านั้น
- การรักษาด้วยตนเอง: การกู้คืนพ็อดโดยอัตโนมัติ (อันเป็นผลมาจากการคืนค่าคอนเทนเนอร์ด้วย)
- การเปิดตัวการอัปเดตและการย้อนกลับของการเปลี่ยนแปลงโดยไม่ต้องหยุดทำงาน: การอัปเดตเครื่องมือ เบราว์เซอร์ และโปรแกรมจำลองจะไม่รบกวนการทำงานของผู้ใช้ปัจจุบัน
แต่ K8 ยังไม่ใช่กระสุนเงิน เพื่อทำความเข้าใจข้อดีและข้อจำกัดทั้งหมดในบริบทของเครื่องมือที่เรากำลังพิจารณา (ตาราง Selenium, Selenoid) เราจะพูดคุยสั้น ๆ เกี่ยวกับโครงสร้างของ K8 คลัสเตอร์ประกอบด้วยโหนดสองประเภท: โหนดหลักและโหนดผู้ปฏิบัติงาน โหนดหลักมีหน้าที่รับผิดชอบในการจัดการ ปรับใช้ และตัดสินใจกำหนดเวลา โหนดผู้ปฏิบัติงานเป็นที่ที่แอปพลิเคชันทำงาน โหนดยังมีสภาพแวดล้อมรันไทม์ของคอนเทนเนอร์ด้วย ในกรณีของเรา นี่คือ Docker ซึ่งรับผิดชอบการดำเนินการที่เกี่ยวข้องกับคอนเทนเนอร์ แต่ก็มีทางเลือกอื่นเช่นกัน. สิ่งสำคัญคือต้องเข้าใจว่าการปรับขนาดหรือการซ่อมแซมตัวเองใช้ไม่ได้กับคอนเทนเนอร์โดยตรง สิ่งนี้ดำเนินการโดยการเพิ่ม/ลดจำนวนพ็อด ซึ่งในทางกลับกันจะมีคอนเทนเนอร์ (โดยปกติจะเป็นหนึ่งคอนเทนเนอร์ต่อพ็อด แต่อาจมีมากกว่านั้นขึ้นอยู่กับงาน) ลำดับชั้นระดับสูงประกอบด้วยโหนดของผู้ปฏิบัติงาน ซึ่งภายในมีพ็อด และภายในคอนเทนเนอร์จะถูกยกขึ้น
คุณลักษณะการปรับขนาดเป็นกุญแจสำคัญและสามารถนำไปใช้กับทั้งสองโหนดภายในโหนดพูลของคลัสเตอร์และพ็อดภายในโหนดได้ การปรับขนาดมี 2 ประเภทที่ใช้กับทั้งโหนดและพ็อด ประเภทแรกคือแนวนอน - การปรับขนาดเกิดขึ้นโดยการเพิ่มจำนวนโหนด/พ็อด ประเภทนี้เป็นที่นิยมมากกว่า ประเภทที่สองคือแนวตั้งตามลำดับ การปรับขนาดจะดำเนินการโดยการเพิ่มขนาดของโหนด/พ็อด ไม่ใช่จำนวน
ตอนนี้เรามาดูเครื่องมือของเราในบริบทของข้อกำหนดข้างต้น
ตารางซีลีเนียม
ดังที่ได้กล่าวไว้ก่อนหน้านี้ ตารางซีลีเนียมเป็นเครื่องมือที่ได้รับความนิยมอย่างมาก และไม่น่าแปลกใจเลยที่กริดจะถูกบรรจุลงในคอนเทนเนอร์ ดังนั้นจึงไม่น่าแปลกใจเลยที่ตาราง Selenium สามารถปรับใช้ใน K8 ได้ ตัวอย่างของวิธีการทำเช่นนี้สามารถพบได้ในที่เก็บ K8s อย่างเป็นทางการ ตามปกติฉันจะแนบลิงก์ไว้ที่ส่วนท้ายของส่วนนี้ นอกจากนี้ คู่มือวิธีใช้ยังแสดงวิธีการทำเช่นนี้ใน Terraform นอกจากนี้ยังมีคำแนะนำเกี่ยวกับวิธีปรับขนาดจำนวนพ็อดที่มีคอนเทนเนอร์ของเบราว์เซอร์อีกด้วย แต่ฟังก์ชันการปรับขนาดอัตโนมัติในบริบทของ K8 ยังไม่ใช่งานที่ชัดเจนนัก เมื่อฉันเริ่มเรียน ฉันไม่พบคำแนะนำหรือคำแนะนำที่เป็นประโยชน์ใดๆ หลังจากการศึกษาและการทดลองหลายครั้งโดยได้รับการสนับสนุนจากทีม DevOps เราได้เลือกวิธีการยกคอนเทนเนอร์ด้วยเบราว์เซอร์ที่จำเป็นภายในพ็อดเดียว ซึ่งตั้งอยู่ภายในโหนดผู้ปฏิบัติงานเดียว วิธีนี้ช่วยให้เราสามารถใช้กลยุทธ์ในการขยายขนาดแนวนอนของโหนดโดยการเพิ่มจำนวน ฉันหวังว่าสิ่งนี้จะเปลี่ยนแปลงในอนาคตและเราจะได้เห็นคำอธิบายเพิ่มเติมเกี่ยวกับวิธีการที่ดีกว่าและวิธีแก้ปัญหาสำเร็จรูป โดยเฉพาะอย่างยิ่งหลังจากการเปิดตัว Selenium grid 4 ที่มีสถาปัตยกรรมภายในที่เปลี่ยนแปลงไป
ซีลีนอยด์:
การใช้งาน Selenoid ใน K8 ถือเป็นความผิดหวังครั้งใหญ่ที่สุดในปัจจุบัน พวกเขาเข้ากันไม่ได้ ตามทฤษฎีแล้ว เราสามารถยกคอนเทนเนอร์ Selenoid ขึ้นภายในพ็อดได้ แต่เมื่อ Selenoid เริ่มเปิดตัวคอนเทนเนอร์ด้วยเบราว์เซอร์ คอนเทนเนอร์เหล่านั้นก็จะยังคงอยู่ในพ็อดเดียวกัน ทำให้ไม่สามารถปรับขนาดได้ และด้วยเหตุนี้ งานของ Selenoid ภายในคลัสเตอร์จะไม่แตกต่างจากงานภายในเครื่องเสมือน ตอนจบของเรื่อง.
ดวงจันทร์:
เมื่อทราบถึงปัญหาคอขวดนี้เมื่อทำงานกับ Selenoid นักพัฒนาจึงได้เปิดตัวเครื่องมือที่ทรงพลังกว่าชื่อ Moon เดิมทีเครื่องมือนี้ได้รับการออกแบบมาให้ทำงานร่วมกับ Kubernetes และด้วยเหตุนี้ คุณจึงสามารถและควรใช้ฟีเจอร์การปรับขนาดอัตโนมัติได้ ยิ่งกว่านั้นฉันจะบอกว่าตอนนี้มันเป็น เท่านั้น เครื่องมือในโลก Selenium ซึ่งมีคลัสเตอร์ K8 ดั้งเดิมรองรับทันที (ไม่มีอีกต่อไป ดูเครื่องมือถัดไป ). คุณสมบัติที่สำคัญของ Moon ที่ให้การสนับสนุนนี้คือ:
ไร้สัญชาติโดยสิ้นเชิง Selenoid จัดเก็บข้อมูลหน่วยความจำเกี่ยวกับเซสชันเบราว์เซอร์ที่กำลังใช้งานอยู่ หากกระบวนการขัดข้องด้วยเหตุผลบางประการ เซสชันที่ทำงานอยู่ทั้งหมดจะสูญหายไป ในทางกลับกัน Moon ไม่มีสถานะภายในและสามารถจำลองแบบข้ามศูนย์ข้อมูลได้ เซสชันของเบราว์เซอร์ยังคงอยู่แม้ว่าแบบจำลองหนึ่งรายการขึ้นไปจะหยุดทำงานก็ตาม
ดังนั้น Moon จึงเป็นทางออกที่ดี แต่มีปัญหาอยู่ประการหนึ่ง นั่นคือ มันไม่ฟรี ราคาขึ้นอยู่กับจำนวนเซสชัน คุณสามารถเรียกใช้เซสชันได้ฟรีเพียง 0-4 เซสชันเท่านั้น ซึ่งไม่มีประโยชน์อย่างยิ่ง แต่ตั้งแต่เซสชันที่ 5 คุณจะต้องจ่าย 500 ดอลลาร์ต่อเซสชัน สถานการณ์อาจแตกต่างกันไปในแต่ละบริษัท แต่ในกรณีของเรา การใช้ Moon นั้นไร้จุดหมาย ดังที่ฉันได้อธิบายไว้ข้างต้น เราสามารถรัน VM ด้วย Selenium Grid ได้ตามความต้องการหรือเพิ่มจำนวนโหนดในคลัสเตอร์ สำหรับไปป์ไลน์ประมาณหนึ่งรายการ เราจะเปิดตัวเบราว์เซอร์ 500 รายการและหยุดทรัพยากรทั้งหมดหลังจากการทดสอบเสร็จสิ้น หากเราใช้ Moon เราจะต้องจ่ายเพิ่ม 5 x 2500 = XNUMX ดอลลาร์ต่อเดือน ไม่ว่าเราจะทำการทดสอบบ่อยแค่ไหนก็ตาม ฉันไม่ได้บอกว่าอย่าใช้ Moon อีกครั้ง สำหรับงานของคุณ นี่อาจเป็นโซลูชันที่ขาดไม่ได้ เช่น หากคุณมีโปรเจ็กต์/ทีมจำนวนมากในองค์กร และคุณต้องการคลัสเตอร์ส่วนกลางขนาดใหญ่สำหรับทุกคน และเช่นเคย ฉันทิ้งลิงก์ไว้ตอนท้ายและแนะนำให้ทำการคำนวณที่จำเป็นทั้งหมดในบริบทของงานของคุณ
Callisto: (ความสนใจ! สิ่งนี้ไม่ได้อยู่ในบทความต้นฉบับและมีอยู่ในการแปลภาษารัสเซียเท่านั้น)
อย่างที่ฉันบอกไปแล้วว่า Selenium เป็นเครื่องมือที่ได้รับความนิยมอย่างมาก และสาขาไอทีก็กำลังพัฒนาอย่างรวดเร็ว ในขณะที่ฉันกำลังแปลอยู่นั้น เครื่องมือใหม่ที่มีแนวโน้มดีที่เรียกว่า Callisto ก็ปรากฏบนเว็บ (สวัสดี Cypress และนักฆ่า Selenium คนอื่นๆ) มันทำงานได้ตามปกติกับ K8 และช่วยให้คุณสามารถรันคอนเทนเนอร์ Selenoid ในพ็อดที่กระจายไปทั่วโหนด ทุกอย่างทำงานได้ตั้งแต่แกะกล่อง รวมถึงการปรับขนาดอัตโนมัติด้วย ยอดเยี่ยม แต่ต้องมีการทดสอบ ฉันได้จัดการปรับใช้เครื่องมือนี้และทำการทดสอบหลายครั้งแล้ว แต่ยังเร็วเกินไปที่จะสรุปผลหลังจากได้ผลลัพธ์มาอย่างยาวนานบางทีฉันอาจจะทำการทบทวนในบทความต่อ ๆ ไป ตอนนี้ฉันเหลือเพียงลิงก์สำหรับการค้นคว้าอิสระเท่านั้น
ภาพประกอบสถานะปัจจุบันของโครงสร้างพื้นฐาน
ลิงค์เพื่อสำรวจ
เครื่องมือที่คล้ายกัน
7. โครงสร้างพื้นฐานเป็นรหัส (IaC)
คำอธิบายโดยย่อของเทคโนโลยี
และตอนนี้เรามาถึงส่วนสุดท้ายแล้ว โดยทั่วไปแล้ว เทคโนโลยีนี้และงานที่เกี่ยวข้องจะไม่อยู่ในความรับผิดชอบของวิศวกรระบบอัตโนมัติ และมีเหตุผลสำหรับเรื่องนี้ ประการแรก ในหลายองค์กร ปัญหาด้านโครงสร้างพื้นฐานอยู่ภายใต้การควบคุมของแผนก DevOps และทีมพัฒนาไม่สนใจจริงๆ ว่าอะไรที่ทำให้ไปป์ไลน์ทำงานได้ และทุกสิ่งที่เกี่ยวข้องกับไปป์ไลน์จำเป็นต้องได้รับการสนับสนุนอย่างไร ประการที่สอง บอกตามตรงว่าแนวปฏิบัติเกี่ยวกับโครงสร้างพื้นฐานในรูปแบบโค้ด (IaC) ยังไม่มีการนำมาใช้ในหลายบริษัท แต่มันกลายเป็นเทรนด์ยอดนิยมอย่างแน่นอน และสิ่งสำคัญคือต้องพยายามมีส่วนร่วมในกระบวนการ แนวทาง และเครื่องมือที่เกี่ยวข้อง หรืออย่างน้อยก็ติดตามข่าวสารอยู่เสมอ
เริ่มต้นด้วยแรงจูงใจในการใช้วิธีการนี้ เราได้พูดคุยกันแล้วว่าในการรันการทดสอบใน GitlabCI เราจะต้องมีทรัพยากรขั้นต่ำในการรัน Gitlab Runner และในการรันคอนเทนเนอร์ด้วยเบราว์เซอร์/อีมูเลเตอร์ เราจำเป็นต้องจอง VM หรือคลัสเตอร์ นอกเหนือจากทรัพยากรการทดสอบแล้ว เรายังต้องการความจุจำนวนมากเพื่อรองรับการพัฒนา การจัดเตรียม สภาพแวดล้อมการใช้งานจริง ซึ่งรวมถึงฐานข้อมูล กำหนดการอัตโนมัติ การกำหนดค่าเครือข่าย โหลดบาลานเซอร์ สิทธิ์ผู้ใช้ และอื่นๆ ประเด็นสำคัญคือความพยายามที่จำเป็นในการสนับสนุนทั้งหมด มีหลายวิธีที่เราสามารถทำการเปลี่ยนแปลงและเปิดตัวการอัปเดตได้ ตัวอย่างเช่น ในบริบทของ GCP เราสามารถใช้คอนโซล UI ในเบราว์เซอร์และดำเนินการทั้งหมดได้ด้วยการคลิกปุ่ม อีกทางเลือกหนึ่งคือใช้การเรียก API เพื่อโต้ตอบกับเอนทิตีระบบคลาวด์ หรือใช้ยูทิลิตีบรรทัดคำสั่ง gcloud เพื่อดำเนินการจัดการที่ต้องการ แต่ด้วยเอนทิตีและองค์ประกอบโครงสร้างพื้นฐานที่แตกต่างกันจำนวนมาก จึงกลายเป็นเรื่องยากหรือเป็นไปไม่ได้เลยที่จะดำเนินการทั้งหมดด้วยตนเอง นอกจากนี้ การดำเนินการโดยเจ้าหน้าที่ทั้งหมดนี้ไม่สามารถควบคุมได้ เราไม่สามารถส่งพวกเขาเข้ารับการตรวจสอบก่อนดำเนินการได้ ใช้ระบบควบคุมเวอร์ชัน และย้อนกลับการเปลี่ยนแปลงที่นำไปสู่เหตุการณ์อย่างรวดเร็ว เพื่อแก้ไขปัญหาดังกล่าว วิศวกรได้สร้างและสร้างสคริปต์ bash/shell อัตโนมัติ ซึ่งไม่ได้ดีไปกว่าวิธีการก่อนหน้านี้มากนัก เนื่องจากไม่ใช่เรื่องง่ายที่จะอ่าน ทำความเข้าใจ บำรุงรักษา และแก้ไขอย่างรวดเร็วในรูปแบบขั้นตอน
ในบทความนี้และคำแนะนำเชิงวิธี ฉันใช้เครื่องมือ 2 รายการที่เกี่ยวข้องกับการฝึกปฏิบัติ IaC เหล่านี้คือ Terraform และ Ansible บางคนเชื่อว่าการใช้พร้อมกันนั้นไม่สมเหตุสมผล เนื่องจากฟังก์ชันการทำงานคล้ายกันและสามารถใช้แทนกันได้ แต่ความจริงก็คือในตอนแรกพวกเขาได้รับมอบหมายงานที่แตกต่างไปจากเดิมอย่างสิ้นเชิง และความจริงที่ว่าเครื่องมือเหล่านี้ควรส่งเสริมซึ่งกันและกันได้รับการยืนยันในการนำเสนอร่วมกันโดยนักพัฒนาที่เป็นตัวแทนของ HashiCorp และ RedHat ความแตกต่างทางแนวคิดคือ Terraform เป็นเครื่องมือจัดเตรียมสำหรับจัดการเซิร์ฟเวอร์ด้วยตนเอง ในขณะที่ Ansible เป็นเครื่องมือจัดการการกำหนดค่าที่มีหน้าที่ติดตั้ง กำหนดค่า และจัดการซอฟต์แวร์บนเซิร์ฟเวอร์เหล่านี้
คุณสมบัติที่แตกต่างที่สำคัญอีกประการหนึ่งของเครื่องมือเหล่านี้คือรูปแบบการเขียนโค้ด ซึ่งแตกต่างจาก bash และ Ansible Terraform ใช้สไตล์การประกาศตามคำอธิบายของสถานะสิ้นสุดที่ต้องการซึ่งจะได้รับจากการดำเนินการ ตัวอย่างเช่น หากเราจะสร้าง 10 VM และใช้การเปลี่ยนแปลงผ่าน Terraform เราก็จะได้ 10 VM หากเราเรียกใช้สคริปต์อีกครั้ง จะไม่มีอะไรเกิดขึ้นเนื่องจากเรามี VM อยู่แล้ว 10 เครื่อง และ Terraform รู้เรื่องนี้เนื่องจากจะเก็บสถานะปัจจุบันของโครงสร้างพื้นฐานไว้ในไฟล์สถานะ แต่ Ansible ใช้วิธีการตามขั้นตอน และหากคุณขอให้สร้าง VM 10 เครื่อง ในการเปิดตัวครั้งแรก เราจะได้รับ 10 VM ซึ่งคล้ายกับ Terraform แต่หลังจากรีสตาร์ทเราจะมี VM 20 เครื่องแล้ว นี่คือความแตกต่างที่สำคัญ ในรูปแบบขั้นตอน เราไม่จัดเก็บสถานะปัจจุบันและเพียงอธิบายลำดับขั้นตอนที่ต้องดำเนินการ แน่นอนว่าเราสามารถจัดการกับสถานการณ์ต่างๆ เพิ่มการตรวจสอบการมีอยู่ของทรัพยากรและสถานะปัจจุบันได้หลายครั้ง แต่ก็ไม่มีประโยชน์ที่จะเสียเวลาและพยายามควบคุมตรรกะนี้ นอกจากนี้ยังเพิ่มความเสี่ยงในการทำผิดพลาดอีกด้วย
เมื่อสรุปทั้งหมดข้างต้น เราสามารถสรุปได้ว่า Terraform และสัญลักษณ์ประกาศเป็นเครื่องมือที่เหมาะสมกว่าสำหรับการจัดเตรียมเซิร์ฟเวอร์ แต่จะเป็นการดีกว่าถ้ามอบหมายงานการจัดการการกำหนดค่าให้กับ Ansible เพื่อไม่ให้เกิดปัญหาดังกล่าว เรามาดูกรณีการใช้งานในบริบทของระบบอัตโนมัติกันดีกว่า
ความคุ้มค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
สิ่งสำคัญเพียงอย่างเดียวที่ต้องทำความเข้าใจที่นี่คือโครงสร้างพื้นฐานการทดสอบอัตโนมัติควรได้รับการพิจารณาให้เป็นส่วนหนึ่งของโครงสร้างพื้นฐานทั้งหมดของบริษัท ซึ่งหมายความว่าแนวปฏิบัติ IaC ทั้งหมดจะต้องนำไปใช้กับทรัพยากรของทั้งองค์กรทั่วโลก ใครเป็นผู้รับผิดชอบเรื่องนี้ขึ้นอยู่กับกระบวนการของคุณ ทีม DevOps มีประสบการณ์มากกว่าในปัญหาเหล่านี้ พวกเขามองเห็นภาพรวมของสิ่งที่เกิดขึ้น อย่างไรก็ตาม วิศวกร QA มีส่วนเกี่ยวข้องมากขึ้นในกระบวนการสร้างระบบอัตโนมัติของอาคารและโครงสร้างของไปป์ไลน์ ซึ่งช่วยให้พวกเขาเห็นการเปลี่ยนแปลงที่จำเป็นทั้งหมดและโอกาสในการปรับปรุงได้ดีขึ้น ทางเลือกที่ดีที่สุดคือการทำงานร่วมกัน แลกเปลี่ยนความรู้และแนวคิดเพื่อให้บรรลุผลตามที่คาดหวัง
นี่คือตัวอย่างบางส่วนของการใช้ Terraform และ Ansible ในบริบทของการทดสอบอัตโนมัติและเครื่องมือที่เราพูดถึงก่อนหน้านี้:
1. อธิบายคุณสมบัติและพารามิเตอร์ที่จำเป็นของ VM และคลัสเตอร์โดยใช้ Terraform
2. ใช้ Ansible ติดตั้งเครื่องมือที่จำเป็นสำหรับการทดสอบ: นักเทียบท่า, Selenoid, Selenium Grid และดาวน์โหลดเบราว์เซอร์/โปรแกรมจำลองเวอร์ชันที่ต้องการ
3. ใช้ Terraform อธิบายคุณลักษณะของ VM ที่ GitLab Runner จะเปิดตัว
4. ติดตั้ง GitLab Runner และเครื่องมือประกอบที่จำเป็นโดยใช้ Ansible ตั้งค่าและการกำหนดค่า
ภาพประกอบสถานะปัจจุบันของโครงสร้างพื้นฐาน
ลิงค์เพื่อสำรวจ:
เครื่องมือที่คล้ายกัน
มาสรุปกัน!
ขั้นตอน
เทคโนโลยี
เครื่องมือ
ความคุ้มค่าสำหรับโครงสร้างพื้นฐานระบบอัตโนมัติ
1
การวิ่งในพื้นที่
Node.js, ซีลีเนียม, Appium
- เครื่องมือยอดนิยมสำหรับเว็บและมือถือ
- รองรับหลายภาษาและแพลตฟอร์ม (รวมถึง Node.js)
2
ระบบควบคุมเวอร์ชัน
ไป
- สิทธิประโยชน์ที่คล้ายกันกับรหัสการพัฒนา
3
การทำตู้คอนเทนเนอร์
นักเทียบท่า, ตารางซีลีเนียม, Selenoid (เว็บ, Android)
- ทำการทดสอบไปพร้อมๆ กัน
- สภาพแวดล้อมที่แยกจากกัน
- การอัพเกรดเวอร์ชันที่เรียบง่ายและยืดหยุ่น
- การหยุดทรัพยากรที่ไม่ได้ใช้แบบไดนามิก
- ติดตั้งง่าย
4
ซีไอ/ซีดี
Gitlab CI
- ทดสอบส่วนหนึ่งของไปป์ไลน์
- ข้อเสนอแนะด่วน
- ทัศนวิสัยสำหรับทั้งบริษัท/ทีมงาน
5
แพลตฟอร์ม Cloud
Google Cloud Platform
- ทรัพยากรตามความต้องการ (เราจ่ายเมื่อจำเป็นเท่านั้น)
- ง่ายต่อการจัดการและอัปเดต
- การมองเห็นและการควบคุมทรัพยากรทั้งหมด
6
orchestration
Kubernetes
ในบริบทของคอนเทนเนอร์ที่มีเบราว์เซอร์/อีมูเลเตอร์อยู่ภายในพ็อด:
- การปรับขนาด/การปรับขนาดอัตโนมัติ
- การรักษาด้วยตนเอง
- การอัปเดตและการย้อนกลับโดยไม่หยุดชะงัก
7
โครงสร้างพื้นฐานเป็นรหัส (IaC)
เทอร์ราฟอร์ม, แอนซิเบิ้ล
- ผลประโยชน์ที่คล้ายกันกับโครงสร้างพื้นฐานการพัฒนา
- ประโยชน์ทั้งหมดของการกำหนดเวอร์ชันโค้ด
- ง่ายต่อการเปลี่ยนแปลงและบำรุงรักษา
- อัตโนมัติเต็มรูปแบบ
แผนภาพแผนที่ความคิด: วิวัฒนาการของโครงสร้างพื้นฐาน
ขั้นตอนที่ 1: ท้องถิ่น
ขั้นตอนที่ 2: วีซีเอส
ขั้นตอนที่ 3: การบรรจุหีบห่อ
ขั้นตอนที่ 4: CI/ซีดี
ขั้นตอนที่ 5: แพลตฟอร์มคลาวด์
ขั้นตอนที่ 6: การเรียบเรียง
ขั้นตอนที่ 7: IaC
ทำอะไรต่อไป
นี่เป็นจุดสิ้นสุดของบทความ แต่โดยสรุปฉันต้องการสร้างข้อตกลงบางอย่างกับคุณ
จากด้านข้างของคุณ
อย่างที่บอกไปตอนต้นว่าอยากให้บทความนี้นำไปใช้ได้จริงและช่วยนำความรู้ที่ได้รับไปประยุกต์ใช้จริง ฉันเพิ่มอีกครั้ง.
แต่หลังจากนั้น อย่าหยุด ฝึกฝน ศึกษาลิงก์และหนังสือที่เกี่ยวข้อง ค้นหาว่ามันทำงานอย่างไรในบริษัทของคุณ ค้นหาสถานที่ที่สามารถปรับปรุงได้ และมีส่วนร่วม ขอให้โชคดี!
ด้านข้างของฉัน
จากชื่อเรื่องจะเห็นว่านี่เป็นเพียงภาคแรกเท่านั้น แม้ว่าจะมีขนาดค่อนข้างใหญ่ แต่หัวข้อสำคัญยังไม่ครอบคลุมที่นี่ ในส่วนที่สอง ฉันวางแผนที่จะดูโครงสร้างพื้นฐานของระบบอัตโนมัติในบริบทของ IOS เนื่องจากข้อจำกัดของ Apple ในการรันโปรแกรมจำลอง iOS บนระบบ macOS เท่านั้น โซลูชันต่างๆ ของเราจึงแคบลง ตัวอย่างเช่น เราไม่สามารถใช้ Docker เพื่อรันโปรแกรมจำลองหรือคลาวด์สาธารณะเพื่อรันเครื่องเสมือนได้ แต่นี่ไม่ได้หมายความว่าไม่มีทางเลือกอื่น ฉันจะพยายามแจ้งให้คุณทราบด้วยโซลูชันขั้นสูงและเครื่องมือที่ทันสมัย!
นอกจากนี้ ฉันยังไม่ได้กล่าวถึงหัวข้อที่ค่อนข้างใหญ่ที่เกี่ยวข้องกับการตรวจสอบ ในส่วนที่ 3 ฉันจะดูเครื่องมือตรวจสอบโครงสร้างพื้นฐานที่ได้รับความนิยมสูงสุด รวมถึงข้อมูลและตัวชี้วัดที่ควรพิจารณา
และในที่สุดก็. ในอนาคต ฉันวางแผนที่จะเผยแพร่หลักสูตรวิดีโอเกี่ยวกับการสร้างโครงสร้างพื้นฐานการทดสอบและเครื่องมือยอดนิยม ปัจจุบันมีหลักสูตรและการบรรยายเกี่ยวกับ DevOps บนอินเทอร์เน็ตค่อนข้างมาก แต่เนื้อหาทั้งหมดจะนำเสนอในบริบทของการพัฒนา ไม่ใช่การทดสอบอัตโนมัติ ในประเด็นนี้ ฉันต้องการคำติชมจริงๆ ว่าหลักสูตรดังกล่าวจะน่าสนใจและมีคุณค่าสำหรับชุมชนผู้ทดสอบและวิศวกรระบบอัตโนมัติหรือไม่ ขอบคุณล่วงหน้า!
ที่มา: will.com