เริ่มใช้เครื่องมือ DevOps ที่ดีที่สุดวันนี้!
ในที่สุดการปฏิวัติ DevOps ก็เข้าครอบงำโลกและเครื่องมือ DevOps ก็ได้รับความนิยมอย่างไม่น่าเชื่อ ตามการบริการ จำนวนคำขอสำหรับ “เครื่องมือ DevOps” มีเพิ่มขึ้นอย่างต่อเนื่อง และแนวโน้มนี้ยังคงดำเนินต่อไป
วิธี DevOps ครอบคลุมวงจรการพัฒนาซอฟต์แวร์ทั้งหมด ดังนั้นมืออาชีพจึงสามารถเลือกใช้เครื่องมือได้หลากหลาย แต่อย่างที่คุณทราบไม่มีเครื่องมือใดที่สามารถกลายเป็นเครื่องมือสากลสำหรับทุกคนได้ อย่างไรก็ตาม โซลูชันบางอย่างมีฟังก์ชันที่หลากหลายซึ่งสามารถรองรับได้เกือบทุกงาน
มาแบ่งเครื่องมือ DevOps ออกเป็นหมวดหมู่แล้วเปรียบเทียบกับอะนาล็อก:
- การพัฒนาและสร้างเครื่องมือ
- ทดสอบเครื่องมืออัตโนมัติ
- เครื่องมือสำหรับจัดระเบียบการใช้งาน
- เครื่องมือรันไทม์
- เครื่องมือการทำงานร่วมกัน
การดำเนินการที่ประสบความสำเร็จและรอบคอบ รวมเครื่องดนตรีจากทั้งห้ากลุ่มที่ระบุไว้ข้างต้น วิเคราะห์ชุดเครื่องมือปัจจุบันในโปรเจ็กต์ของคุณ เพื่อไม่ให้พลาดองค์ประกอบสำคัญของไปป์ไลน์ CI/CD
เครื่องมือการพัฒนาและสร้าง
นี่คือพื้นฐานของสแต็กไปป์ไลน์ CI/CD ทุกอย่างเริ่มต้นที่นี่! เครื่องมือที่ดีที่สุดในหมวดหมู่นี้สามารถจัดการสตรีมกิจกรรมได้หลายรายการและรวมเข้ากับผลิตภัณฑ์อื่น ๆ ได้อย่างง่ายดาย
ในขั้นตอนของวงจรชีวิตการพัฒนานี้ มีเครื่องมือสามกลุ่ม:
- ระบบควบคุมเวอร์ชัน (SCM)
- การบูรณาการอย่างต่อเนื่อง (CI)
- การจัดการข้อมูล
GIT มีประวัติเชิงบวกในปี 2020 ดังนั้นเครื่องมือ SCM ของคุณจึงควรได้รับการสนับสนุน GIT ได้อย่างราบรื่น สำหรับ CI สิ่งที่จำเป็นต้องมีคือความสามารถในการดำเนินการและรันบิลด์ในสภาพแวดล้อมคอนเทนเนอร์ที่แยกออกมา เมื่อพูดถึงการจัดการข้อมูล จำเป็นต้องมีความสามารถในการเปลี่ยนแปลงสคีมาฐานข้อมูลและดูแลรักษาฐานข้อมูลตามเวอร์ชันของแอปพลิเคชัน
เครื่องมือ SCM + CI #1
ผู้ชนะ: GitLab และ GitLab-CI
เครื่องมือที่ดีที่สุดของวัฏจักร DevOps ปี 2020 ไม่ต้องสงสัยเลยว่า GitLab และจะยังคงเป็นผู้นำด้านนวัตกรรมต่อไปในอนาคตอันใกล้นี้อย่างแน่นอน
หน้าที่หลักของ GitLab คือการจัดการพื้นที่เก็บข้อมูล Git ที่สะดวกสบาย เว็บอินเตอร์เฟสใช้งานง่ายและใช้งานง่าย GitLab มอบทุกสิ่งที่คุณต้องการในเวอร์ชันฟรีและมาในรูปแบบ SaaS และภายในองค์กร (ใช้ทรัพยากรของคุณเองเพื่อโฮสต์ซอฟต์แวร์)
ไม่มีเครื่องมือ SCM อื่นใดที่ใช้การผสานรวมอย่างต่อเนื่อง (CI) บนพื้นที่เก็บข้อมูลของคุณโดยตรง และ GitLab ทำสิ่งนี้มาเป็นเวลานาน หากต้องการใช้ GitLab-CI คุณต้องเพิ่มไฟล์ .gitlab-ci.yml ไปยังรูทซอร์สโค้ดของคุณ และการเปลี่ยนแปลงใดๆ ในโปรเจ็กต์จะทริกเกอร์การดำเนินการตามสิ่งที่คุณระบุไว้ GitLab และ GitLab-CI สมควรได้รับการยอมรับว่าเป็นผู้นำในด้านการบูรณาการอย่างต่อเนื่อง (CI-as-code)
ประโยชน์ที่สำคัญ
- ความน่าเชื่อถือ - ผลิตภัณฑ์ออกสู่ตลาดตั้งแต่ปี 2013 มั่นคง; ได้รับการสนับสนุนอย่างดี
- โอเพ่นซอร์ส - GitLab เวอร์ชันฟรีไม่จำกัดฟังก์ชันการทำงานหลักที่ทีมพัฒนาต้องการ แพ็คเกจบริการแบบชำระเงินมีฟีเจอร์ที่เป็นประโยชน์เพิ่มเติมสำหรับบริษัทที่มีขนาดและความต้องการต่างกัน
- Engrained CI - ไม่มีเครื่องมืออื่นใดในตลาดที่สร้างการบูรณาการอย่างต่อเนื่องเข้ากับ SCM โดยตรงเช่น GitLab-CI การใช้ Docker ช่วยให้มั่นใจได้ว่าบิลด์แยกจะไม่ยุ่งยาก และรายงานในตัวทำให้การดีบักเป็นเรื่องง่าย เราไม่ต้องการการบูรณาการและการจัดการที่ซับซ้อนของเครื่องมือหลายอย่างในเวลาเดียวกัน
- การบูรณาการแบบไม่จำกัด - GitLab มอบการบูรณาการเครื่องมือ DevOps ทั้งหมดที่คุณต้องการได้อย่างง่ายดาย สิ่งนี้ทำให้มั่นใจได้ว่าทีมพัฒนาและบำรุงรักษามีแหล่งข้อมูลเดียวเกี่ยวกับการใช้งานของพวกเขาในทุกสภาพแวดล้อม
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
มีเครื่องมือยอดนิยมอื่น ๆ ในหมวดหมู่นี้ แต่เครื่องมือเหล่านั้นยังไม่ดีเท่า GitLab และนั่นคือเหตุผล:
GitHub — นี่คือระบบควบคุมเวอร์ชัน SaaS ที่ยอดเยี่ยมสำหรับบริษัทขนาดเล็กและระยะเริ่มต้นของการพัฒนา สำหรับบริษัทขนาดใหญ่ที่จำเป็นต้องเก็บที่อยู่ IP ไว้ในเครือข่ายของตนเอง ทางออกเดียวจาก GitHub คือเครื่องเสมือน .OVA ที่ไม่รองรับระบบที่มีความพร้อมใช้งานสูง ซึ่งทำให้การบำรุงรักษาภายในองค์กรทำได้ยาก นอกจากนี้ .OVA ยังเหมาะสำหรับธุรกิจขนาดกลางเท่านั้น ไม่เช่นนั้น เซิร์ฟเวอร์จะเสียหายหากมีภาระงานมากขึ้น การไม่มี GitHub Actions (จนกระทั่งเมื่อเร็วๆ นี้และยังไม่มีในเวอร์ชันภายในองค์กร) หรือ CI-as-code หมายความว่าคุณต้องเลือกเครื่องมือ CI แยกต่างหาก จากนั้นจึงจัดการการผสานรวมนั้น ในที่สุด GitHub ก็มีราคาแพงกว่า GitLab เวอร์ชันใดเวอร์ชันหนึ่งมาก
เจนกิ้นส์ — แม้ว่า Jenkins จะถือเป็นมาตรฐานในบรรดาเครื่องมือบูรณาการอย่างต่อเนื่องตามค่าเริ่มต้น แต่ก็ยังขาดความสามารถในการควบคุมเวอร์ชันอยู่เสมอ ปรากฎว่าคุณกำลังใช้ Jenkins บวกกับเครื่องมือ SCM บางประเภท มันยากเกินไปเมื่อ GitLab สามารถทำได้ทั้งสองอย่าง การออกแบบ UX ปานกลางไม่เหมาะกับเว็บแอปพลิเคชันสมัยใหม่และยังเป็นที่ต้องการอีกมาก
BitBucket/ไม้ไผ่ — ฉันต้องยอมรับว่าเขาเป็นผู้แพ้โดยอัตโนมัติ: ทำไมต้องมีเครื่องมือสองตัวในเมื่อ GitLab ทำทุกอย่างอย่างอิสระโดยสมบูรณ์ BitBucket Cloud รองรับฟังก์ชัน GitLab-CI / GitHub Action แต่ไม่มีบริษัทใดที่ใหญ่กว่าสตาร์ทอัพจะสามารถใช้งานได้ง่าย เซิร์ฟเวอร์ BitBucket ภายในองค์กรไม่รองรับไปป์ไลน์ BitBucket ด้วยซ้ำ!
เครื่องมือการจัดการข้อมูล #1
ผู้ชนะ: ฟลายเวย์ดีบี
ในการพัฒนาเว็บแอปพลิเคชัน โดยปกติแล้วระบบฐานข้อมูลอัตโนมัติจะไม่ให้ความสำคัญ แนวคิดในการปรับใช้การเปลี่ยนแปลงสคีมาฐานข้อมูลสำหรับแอปพลิเคชันเวอร์ชันใหม่มาช้า การเปลี่ยนแปลงสคีมามักส่งผลให้มีการเพิ่มและเปลี่ยนชื่อคอลัมน์หรือตาราง หากเวอร์ชันของแอปพลิเคชันไม่ตรงกับเวอร์ชันของสคีมา แอปพลิเคชันอาจหยุดทำงาน นอกจากนี้ การจัดการการเปลี่ยนแปลงฐานข้อมูลเมื่ออัปเดตแอปพลิเคชันอาจเป็นเรื่องที่ท้าทายเนื่องจากมีระบบที่แตกต่างกันสองระบบ FlyWayDB แก้ปัญหาเหล่านี้ได้ทั้งหมด
ประโยชน์ที่สำคัญ
- การกำหนดเวอร์ชันฐานข้อมูล - Flyway ช่วยให้คุณสร้างเวอร์ชันฐานข้อมูล ติดตามการย้ายฐานข้อมูล และถ่ายโอนหรือเปลี่ยนกลับการเปลี่ยนแปลงสคีมาได้อย่างง่ายดายโดยไม่ต้องใช้เครื่องมือเพิ่มเติมสำหรับสิ่งนี้
- ไบนารีหรือฝังตัว - เราสามารถเลือกรัน Flyway เป็นส่วนหนึ่งของแอปพลิเคชันหรือเป็นไฟล์ปฏิบัติการไบนารีได้ Flyway ตรวจสอบความเข้ากันได้ของเวอร์ชันเมื่อเริ่มต้นระบบ และเริ่มการโยกย้ายที่เหมาะสม โดยรักษาฐานข้อมูลและเวอร์ชันแอปพลิเคชันให้ตรงกัน ด้วยการรันคำสั่ง ad-hoc บรรทัด cmd เราจะมอบความยืดหยุ่นให้กับฐานข้อมูลที่มีอยู่โดยไม่ต้องสร้างแอปพลิเคชันใหม่ทั้งหมด
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
มีเครื่องมือไม่มากในบริเวณนี้ ลองดูบางส่วนของพวกเขา:
LiquiBase — Liquibase มีลักษณะคล้ายกับ FlywayDB ฉันต้องการตั้งค่าไว้บน Flyway หากมีคนในทีมที่มีประสบการณ์กับ Liquibase มากกว่า
โฟลคเกอร์ - ใช้งานได้กับแอปพลิเคชันแบบคอนเทนเนอร์เท่านั้น เพื่อให้รันฐานข้อมูลแบบคอนเทนเนอร์ได้สำเร็จ ทุกอย่างจะต้องได้รับการวางแผนอย่างสมบูรณ์แบบ ฉันแนะนำให้ใช้ RDS (Relational Database Service) สำหรับฐานข้อมูลและไม่แนะนำให้จัดเก็บข้อมูลสำคัญไว้ในคอนเทนเนอร์
ทดสอบเครื่องมืออัตโนมัติ
เรามาเริ่มการสนทนาเกี่ยวกับเครื่องมือทดสอบอัตโนมัติโดยการจัดประเภทตามปิรามิดการทดสอบ
ปิรามิดการทดสอบ (การทดสอบ) มี 4 ระดับ:
- การทดสอบหน่วย - นี่คือพื้นฐานของกระบวนการทดสอบอัตโนมัติทั้งหมด ควรมีการทดสอบหน่วยมากกว่าเมื่อเทียบกับการทดสอบประเภทอื่น นักพัฒนาเขียนและรันการทดสอบหน่วยเพื่อให้แน่ใจว่าส่วนหนึ่งของแอปพลิเคชัน (เรียกว่า "หน่วย") สอดคล้องกับการออกแบบและทำงานตามที่คาดไว้
- การทดสอบส่วนประกอบ - วัตถุประสงค์หลักของการทดสอบส่วนประกอบคือการตรวจสอบพฤติกรรมอินพุต/เอาท์พุตของวัตถุทดสอบ เราต้องตรวจสอบให้แน่ใจว่ามีการใช้ฟังก์ชันการทำงานของวัตถุทดสอบอย่างถูกต้องตามข้อกำหนด
- การทดสอบการรวม - ประเภทของการทดสอบที่โมดูลซอฟต์แวร์แต่ละตัวถูกรวมและทดสอบเป็นกลุ่ม
- การทดสอบแบบครบวงจร - ขั้นตอนนี้อธิบายได้ในตัว เราตรวจสอบแอปพลิเคชันทั้งหมดและตรวจสอบให้แน่ใจว่าทำงานได้ตามที่วางแผนไว้
เนื่องจากการทดสอบหน่วยและการทดสอบส่วนประกอบดำเนินการโดยนักพัฒนาเท่านั้น และมักจะเป็นภาษาการเขียนโปรแกรมโดยเฉพาะ เราจะไม่ประเมินเครื่องมือเหล่านี้สำหรับโดเมน DevOps
เครื่องมือทดสอบการรวมระบบ #1
ผู้ชนะ: แตงกวา
Cucumber รวมข้อกำหนดและเอกสารการทดสอบไว้ในเอกสารการดำรงชีวิตฉบับเดียว ข้อมูลจำเพาะเป็นข้อมูลล่าสุดอยู่เสมอเนื่องจาก Cucumber ทดสอบโดยอัตโนมัติ หากคุณต้องการสร้างเฟรมเวิร์กการทดสอบอัตโนมัติตั้งแต่เริ่มต้นและจำลองพฤติกรรมผู้ใช้ในเว็บแอปพลิเคชัน Selenium WebDriver พร้อม Java และ Cucumber BDD เป็นวิธีที่ยอดเยี่ยมในการเรียนรู้และนำ Cucumber ไปใช้งานในโปรเจ็กต์
ประโยชน์ที่สำคัญ
- วิธี BDD (การพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม - "การพัฒนาผ่านพฤติกรรม" ตรงข้ามกับแนวทาง "การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ") - แตงกวาได้รับการออกแบบมาสำหรับการทดสอบ BDD แต่เดิมถูกสร้างขึ้นเพื่องานนี้โดยเฉพาะ
- Living Documentation - เอกสารเป็นสิ่งที่เจ็บปวดเสมอ! เนื่องจากการทดสอบของคุณเขียนเป็นโค้ด Cucumber จึงทดสอบเอกสารที่สร้างขึ้นโดยอัตโนมัติเพื่อให้แน่ใจว่าการทดสอบและเอกสารประกอบสอดคล้องกัน
- การสนับสนุน - เราสามารถเลือกเครื่องมือได้มากมาย แต่ Cucumber มีทรัพยากรทางการเงินที่จำเป็นและระบบสนับสนุนที่ได้รับการจัดการอย่างดีเพื่อช่วยเหลือผู้ใช้ในสถานการณ์ที่ยากลำบาก
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
ในบรรดาเฟรมเวิร์กและเครื่องมือเฉพาะทางเทคโนโลยีอื่นๆ มีเพียงแตงกวาเท่านั้นที่ถือเป็นโซลูชันสากล
เครื่องมือทดสอบแบบครบวงจร
เมื่อทำการทดสอบแบบ end-to-end คุณต้องมุ่งเน้นไปที่ประเด็นสำคัญสองประการ:
- การทดสอบการทำงาน
- การทดสอบความเครียด
ในการทดสอบการทำงาน เราจะตรวจสอบว่าทุกสิ่งที่เราต้องการเกิดขึ้นจริงหรือไม่ ตัวอย่างเช่น เมื่อฉันคลิกที่องค์ประกอบบางอย่างของ SPA ของฉัน (แอปพลิเคชันหน้าเดียว) กรอกแบบฟอร์มและเลือก "ส่ง" ข้อมูลจะปรากฏในฐานข้อมูลและข้อความ "สำเร็จ!" จะปรากฏบนหน้าจอ
สิ่งสำคัญสำหรับเราคือการตรวจสอบว่าผู้ใช้จำนวนหนึ่งที่ทำงานในสถานการณ์เดียวกันสามารถประมวลผลได้โดยไม่มีข้อผิดพลาด
การไม่มีการทดสอบ 2 ประเภทนี้จะเป็นข้อเสียเปรียบที่สำคัญในไปป์ไลน์ CI/CD ของคุณ
เครื่องมือทดสอบแบบครบวงจรอันดับ 1 การทดสอบการทำงาน
ผู้ชนะ: โซปยูไอ โปร
SoapUI อยู่ในพื้นที่ทดสอบ API มาเป็นเวลานานเนื่องจากบริการเว็บที่ใช้ SOAP เป็นมาตรฐาน แม้ว่าเราจะไม่สร้างบริการ SOAP ใหม่อีกต่อไป และชื่อของเครื่องมือก็ไม่เปลี่ยนแปลง แต่นั่นไม่ได้หมายความว่าเครื่องมือนั้นไม่มีการพัฒนา SoapUI มอบกรอบการทำงานที่ยอดเยี่ยมสำหรับการสร้างการทดสอบการทำงานของแบ็กเอนด์อัตโนมัติ สามารถรวมการทดสอบเข้ากับเครื่องมือบูรณาการอย่างต่อเนื่อง และใช้เป็นส่วนหนึ่งของไปป์ไลน์ CI/CD ได้อย่างง่ายดาย
ประโยชน์ที่สำคัญ
- เอกสารประกอบโดยละเอียด - SoapUI อยู่ในตลาดมาเป็นเวลานาน ดังนั้นจึงมีแหล่งข้อมูลออนไลน์มากมายที่สามารถช่วยให้คุณเข้าใจวิธีตั้งค่าการทดสอบ
- ใช้งานง่าย - แม้ว่าเครื่องมือจะรองรับหลายโปรโตคอลสำหรับการทดสอบ API แต่การมีอินเทอร์เฟซทั่วไปของ SoapUI สำหรับบริการหลายอย่างทำให้การทดสอบการเขียนง่ายขึ้น
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
ซีลีเนียม เป็นอีกหนึ่งเครื่องดนตรีที่ยอดเยี่ยมในกลุ่มนี้ ฉันแนะนำให้ใช้มันหากคุณกำลังสร้างและใช้งานแอปพลิเคชันที่ใช้ Java อย่างไรก็ตาม หากคุณกำลังสร้างเว็บแอปพลิเคชันเต็มรูปแบบด้วยเทคโนโลยีที่หลากหลาย อาจกลายเป็นเรื่องยุ่งยากสำหรับส่วนประกอบที่ไม่ใช่ Java
เครื่องมือทดสอบแบบครบวงจรอันดับ 1 การทดสอบความเครียด
ผู้ชนะ: โหลดรันเนอร์
คำอธิบาย: เมื่อถึงเวลาทดสอบโหลดทุกองค์ประกอบของแอปพลิเคชันของคุณ มีเพียง LoadRunner เท่านั้นที่สามารถทำงานได้ ใช่ มันมีราคาแพงและยากในตอนแรก แต่ LoadRunner เป็นเครื่องมือเดียวที่ทำให้ฉันในฐานะสถาปนิกด้านเทคนิค มั่นใจได้อย่างเต็มเปี่ยมว่าโค้ดใหม่จะทำงานภายใต้สภาวะโหลดที่หนักหน่วง นอกจากนี้ ฉันคิดว่าถึงเวลาแล้วที่ LoadRunner จะถูกทีมพัฒนาเข้ามาแทนที่ ไม่ใช่ทีมทดสอบ
ประโยชน์ที่สำคัญ
- เอกสารประกอบที่ครอบคลุม - LoadRunner เข้าสู่ตลาดมาระยะหนึ่งแล้ว ดังนั้นจึงมีแหล่งข้อมูลออนไลน์มากมายที่จะช่วยให้คุณเข้าใจวิธีตั้งค่าการทดสอบโหลด
- การสนับสนุนโปรโตคอล - Load Runner รองรับทุกอย่างตั้งแต่ ODBC ไปจนถึง AJAX, HTTPS และโปรโตคอลอื่น ๆ ที่ไม่สำคัญอื่น ๆ ที่แอปพลิเคชันของคุณอาจใช้ เราพยายามที่จะไม่ใช้เครื่องมือหลายอย่างในการทดสอบโหลด เนื่องจากจะทำให้กระบวนการยุ่งยากเท่านั้น
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
ขอย้ำอีกครั้งว่า ไม่มีเครื่องมือสากลมากมายในพื้นที่นี้ ดังนั้นทางออกที่ดีที่สุดคือเครื่องมือที่สามารถทำงานในสภาพแวดล้อมใดๆ ก็ตามที่มีเทคโนโลยีใดก็ได้
เครื่องมือการปรับใช้
เครื่องมือการปรับใช้อาจเป็นแง่มุมในการพัฒนาที่เข้าใจน้อยที่สุด สำหรับทีมปฏิบัติการที่ไม่มีความเข้าใจอย่างลึกซึ้งเกี่ยวกับโค้ดและฟังก์ชันการทำงานของแอปพลิเคชัน การใช้เครื่องมือดังกล่าวเป็นเรื่องยาก สำหรับนักพัฒนา การจัดการการปรับใช้ถือเป็นความรับผิดชอบใหม่ ดังนั้นพวกเขาจึงยังไม่มีประสบการณ์เพียงพอในการทำงานกับเครื่องมือดังกล่าว
ก่อนอื่น เรามาแบ่งเครื่องมือการปรับใช้ทั้งหมดออกเป็นสามหมวดหมู่ย่อย:
- การจัดการสิ่งประดิษฐ์
- การจัดการการตั้งค่า
- ปรับใช้.
เครื่องมือการจัดการสิ่งประดิษฐ์อันดับ 1
ผู้ชนะ: Nexus
พื้นที่เก็บข้อมูลสิ่งประดิษฐ์ของ Nexus รองรับเทคโนโลยีหลักเกือบทุกประเภท ตั้งแต่ Java ไปจนถึง NPM ไปจนถึง Docker เราสามารถใช้เครื่องมือนี้เพื่อจัดเก็บสิ่งประดิษฐ์ทั้งหมดที่เราใช้ การใช้พร็อกซีตัวจัดการแพ็คเกจระยะไกลยังช่วยเร่งกระบวนการสร้าง CI ได้อย่างมาก ทำให้สามารถเข้าถึงแพ็คเกจสำหรับการสร้างได้มากขึ้น ข้อดีอีกประการหนึ่งคือความสามารถในการรับมุมมองที่สมบูรณ์ของแพ็คเกจทั้งหมดที่ใช้ในโครงการซอฟต์แวร์หลาย ๆ โครงการ โดยบล็อกแพ็คเกจโอเพ่นซอร์สที่ไม่ปลอดภัย (สามารถทำหน้าที่เป็นเวกเตอร์การโจมตีได้)
ประโยชน์ที่สำคัญ
- การสนับสนุนด้านเทคนิค - ผลิตภัณฑ์ที่เชื่อถือได้ ได้รับการสนับสนุนอย่างดี
- โอเพ่นซอร์ส - เวอร์ชันฟรีไม่จำกัดฟังก์ชันหลักที่ทีมพัฒนาต้องการ
เครื่องมือการจัดการการกำหนดค่า #1
ผู้ชนะ: เบิ้ล
Ansible เป็นผู้นำด้วยเหตุผลง่ายๆ ประการเดียว นั่นคือ ไร้สัญชาติ ก่อนหน้านี้ เครื่องมือที่คล้ายกันมุ่งเน้นไปที่การจัดการสถานะการกำหนดค่า เมื่อเปิดตัว เครื่องมือดังกล่าวเมื่อได้รับการกำหนดค่าที่ต้องการแล้ว จะพยายามแก้ไขการกำหนดค่าแอปพลิเคชันปัจจุบัน และด้วยแนวทางใหม่นี้ มีเพียงส่วนประกอบไร้สัญชาติเท่านั้นที่มีอยู่ โค้ดเวอร์ชันใหม่คือส่วนที่สร้างขึ้นเพื่อแทนที่โค้ดที่มีอยู่ นี่ถือได้ว่าเป็นสภาพแวดล้อมชั่วคราวระยะสั้น
ประโยชน์ที่สำคัญ
- ไร้สถานะ - Playbook ถูกเปิดใช้งานจากเครื่องปรับใช้และดำเนินการบนเซิร์ฟเวอร์เป้าหมาย ฉันไม่ต้องกังวลเกี่ยวกับสถานะของออบเจ็กต์ระยะไกลด้วยการใช้เครื่องมือเช่น Packer เพื่อสร้างออบเจ็กต์ที่ปรับใช้ได้
- โอเพ่นซอร์ส - เช่นเดียวกับ CentOS RedHat ก็รองรับ Ansible เช่นกัน ช่วยรักษาชุมชนและมอบโมดูลคุณภาพสูงและใช้งานง่าย
- การทดสอบด้วยโมเลกุล (เฟรมเวิร์ก Ansible) - เนื่องจากการจัดการการกำหนดค่านั้นเป็นโค้ด เช่นเดียวกับอย่างอื่น การทดสอบจึงเป็นสิ่งจำเป็น เฟรมเวิร์กการทดสอบบทบาท Ansible ของ Molecule ทำงานได้อย่างไร้ที่ติ ทำให้มั่นใจได้ว่าการกำหนดค่ามีคุณภาพเหมือนกัน และเป็นไปตามไปป์ไลน์ CI/CD เดียวกันกับโค้ดแอปพลิเคชัน
- YAML - เมื่อเทียบกับเครื่องมืออื่นๆ YAML เข้าใจได้ง่ายกว่า เนื่องจากโดยทั่วไปแล้วการจัดการการกำหนดค่าถือเป็นความท้าทายใหม่สำหรับผู้ที่นำแนวทางปฏิบัติ DevOps ไปใช้ ความเรียบง่ายจึงเป็นสิ่งสำคัญ
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
เชฟ OpsCode — ฉันเริ่มต้นอาชีพ DevOps ในฐานะนักพัฒนาตำราอาหาร แน่นอนว่า Ruby และ Chef เป็นที่รักของฉันมาก แต่พวกเขาไม่ได้แก้ปัญหาของแอปพลิเคชันไร้สัญชาติสมัยใหม่บนคลาวด์เลย OpsCode Chef เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการใช้งานแบบดั้งเดิม แต่ในบทความนี้ เราจะมุ่งเน้นไปที่อนาคต
หุ่นเชิด — Puppet ไม่เคยมีแฟนๆ มากนัก โดยเฉพาะเมื่อเปรียบเทียบกับ Chef และ Ansible เหมาะอย่างยิ่งสำหรับการจัดเตรียมและทำงานกับฮาร์ดแวร์ แต่ขาดการสนับสนุนการจัดการการกำหนดค่าที่ทันสมัยสำหรับเว็บแอปพลิเคชัน
เครื่องมือปรับใช้ #1
ผู้ชนะ: terraform
Terraform แก้ปัญหาในการอธิบายโครงสร้างพื้นฐานของคุณเป็นโค้ด ตั้งแต่ส่วนประกอบเครือข่ายไปจนถึงอิมเมจเซิร์ฟเวอร์เต็มรูปแบบ ผลิตภัณฑ์นี้พัฒนาไปไกลนับตั้งแต่เปิดตัวครั้งแรก โดยมีปลั๊กอินที่สร้างขึ้นมากมายและมีชุมชนที่แข็งแกร่งซึ่งคุณจะได้รับความช่วยเหลือในทุกสถานการณ์ในการใช้งาน ความสามารถในการรองรับสภาพแวดล้อมทุกประเภท (ภายในองค์กร ในระบบคลาวด์ หรือที่อื่นๆ) นั้นไม่มีใครเทียบได้ สุดท้ายนี้ เวอร์ชันล่าสุดมีฟังก์ชันและคลาสตรรกะใน HCL เหมือนกับภาษาการเขียนโปรแกรมทั่วไปอื่นๆ ทำให้นักพัฒนา Terraform เข้าใจได้อย่างรวดเร็วและง่ายดาย
ประโยชน์ที่สำคัญ
- ไม่เชื่อเรื่องสภาพแวดล้อม - Terraform ใช้ฟังก์ชันที่ทำหน้าที่เป็นอินเทอร์เฟซระหว่างโค้ด Terraform, API ทั้งหมด และตรรกะภายในเพื่อสื่อสารกับผู้ให้บริการโครงสร้างพื้นฐาน ซึ่งหมายความว่าฉันจะเชี่ยวชาญเครื่องมือเพียงชิ้นเดียวแล้วจึงทำงานได้ทุกที่
- Open Source - ยากที่จะเอาชนะเครื่องมือฟรี! การสนับสนุนจากชุมชนในระดับสูงสุด
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
การก่อตัวของ AWS Cloud — แม้ว่าคุณจะทำงานในสภาพแวดล้อมคลาวด์ AWS เท่านั้น งานต่อไปของคุณอาจใช้เครื่องมืออื่น การอุทิศเวลาและพลังงานทั้งหมดของคุณให้กับแพลตฟอร์มเดียวถือเป็นการตัดสินใจระยะสั้น นอกจากนี้ บริการ AWS ใหม่จำนวนมากมักจะพร้อมใช้งานเป็นโมดูล Terraform ก่อนที่จะพร้อมใช้งานใน CloudFormation
เครื่องมือรันไทม์
เป้าหมายสูงสุดของโครงการพัฒนาใดๆ ก็คือการนำแอปพลิเคชันไปใช้จริง ในโลกของ DevOps เราต้องการทราบถึงปัญหาที่อาจเกิดขึ้นทั้งหมดกับสภาพแวดล้อมของเรา และเรายังต้องการลดการแทรกแซงด้วยตนเองให้เหลือน้อยที่สุดด้วย การเลือกชุดเครื่องมือรันไทม์ที่เหมาะสมถือเป็นสิ่งสำคัญในการบรรลุนิพพานการพัฒนาแอปพลิเคชัน
หมวดหมู่ย่อยของเครื่องมือรันไทม์:
- X-as-a-บริการ (XaaS)
- การเรียบเรียง
- การตรวจสอบ
- การบันทึก
X-tool-as-a-บริการ #1
ผู้ชนะ: Amazon Web Services
Amazon เป็นผู้นำในด้านเทคโนโลยีคลาวด์มาโดยตลอด แต่ไม่ได้หยุดอยู่แค่นั้น บริการใหม่ๆ ที่หลากหลายสำหรับนักพัฒนากำลังเปิดหูเปิดตา นำเทคโนโลยีและเทมเพลตมาสู่ AWS แล้วมันจะถูกสร้างขึ้นและใช้งาน ต้นทุนของเครื่องมือค่อนข้างสมเหตุสมผล: เปรียบเทียบกับการประกอบ การจัดการ และการบำรุงรักษาอุปกรณ์ในศูนย์ข้อมูลของคุณเอง เวอร์ชันฟรีช่วยให้คุณทดลองและตัดสินใจได้ถูกต้องก่อนใช้จ่ายเงิน
ประโยชน์ที่สำคัญ
- ความแพร่หลาย - หากคุณมีประสบการณ์ในการสร้างแอปพลิเคชันใน AWS คุณสามารถทำงานได้ทุกที่ ธุรกิจต่างชื่นชอบ AWS และบริษัทสตาร์ทอัพก็พอใจกับต้นทุนที่ต่ำเช่นกัน
- เวอร์ชันฟรีเป็นปัจจัยสำคัญอย่างแท้จริงที่ทำให้ AWS แตกต่างจากคู่แข่ง ให้ฉันลองใช้บริการดูว่ามันทำงานอย่างไรก่อนตัดสินใจซื้อ ฉันไม่อยากเสียเงินหลายพันไปกับสิ่งที่ไม่จำเป็น เวอร์ชันฟรีนั้นเพียงพอสำหรับฉันเสมอที่จะทดสอบแนวคิดต่างๆ
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
สีฟ้า “Azure มาไกลตั้งแต่เปิดตัวครั้งแรก และนั่นก็น่ายกย่อง อย่างไรก็ตาม ความปรารถนาที่จะแตกต่างทำให้เกิดชื่อบริการแปลกๆ ซึ่งมักจะทำให้งานซับซ้อน "ที่เก็บข้อมูลหยด" หมายถึงอะไร และแม้ว่าโค้ด .NET จะทำงานได้ดีกว่าในระบบนิเวศของ Microsoft แต่ก็ไม่น่าเป็นไปได้ที่คุณจะใช้เพียง .NET สำหรับทุกองค์ประกอบของแอปพลิเคชันของคุณ
Heroku — ฉันจะไม่ดำเนินการใดๆ นอกเหนือจากโครงการส่วนตัวบน Heroku เนื่องจากความน่าเชื่อถือและความโปร่งใสในระดับต่ำ ดังนั้นบริษัทต่างๆ จึงไม่ควรใช้มันเป็นแพลตฟอร์ม Heroku นั้นยอดเยี่ยมสำหรับการสาธิตบางสิ่งบนบล็อก แต่สำหรับการใช้งานจริง - "ไม่ ขอบคุณ!"
เครื่องมือการเรียบเรียง #1
ผู้ชนะ: เปิดกะ
คุณอาจใช้ Docker หรือคอนเทนเนอร์อื่นๆ ในสแต็กแอปพลิเคชันของคุณ แอปพลิเคชันแบบไร้เซิร์ฟเวอร์นั้นดี แต่อาจไม่เหมาะกับทุกสถาปัตยกรรม การเรียกใช้คอนเทนเนอร์โดยไม่มีแพลตฟอร์มการประสานจะไม่ทำงาน Kubernetes Core (K8s) ไม่มีคู่แข่งในแง่ของความปลอดภัยและเครื่องมือ OpenShift เป็นแพลตฟอร์มที่ใช้ Kubernetes เพียงแพลตฟอร์มเดียวที่สามารถรวบรวม Source2Image รองรับการปรับใช้อัตโนมัติบนพ็อด และรองรับการติดตามและการตรวจสอบ OpenShift สามารถทำงานภายในองค์กร ในระบบคลาวด์ หรือภายในองค์กร และในระบบคลาวด์ได้ในเวลาเดียวกัน
ประโยชน์ที่สำคัญ
- การรักษาความปลอดภัยในตัว - การจัดการความปลอดภัยของ K8 อาจต้องมีระดับสูง ทุกรายละเอียดจะต้องคิดและนำมาพิจารณาอย่างรอบคอบ! กลไกการรักษาความปลอดภัยที่ติดตั้งไว้เป็นค่าเริ่มต้นด้วย OpenShift จะช่วยแบ่งเบาภาระของนักพัฒนาและมอบแพลตฟอร์มที่ปลอดภัยยิ่งขึ้นสำหรับแอปพลิเคชัน
- โซลูชันแบบครบวงจร - ต่างจาก K8 พื้นฐานซึ่งไม่มีเครื่องมือปรับสมดุลโหลดตามค่าเริ่มต้น OpenShift มีครบทุกอย่าง ฉันสามารถใช้มันเพื่อสร้างและโฮสต์คอนเทนเนอร์ เรียกใช้เครื่องมือ CI/CD จัดการกระบวนการภายนอก จัดการคีย์ และอื่นๆ อีกมากมาย แม้ว่าอินเทอร์เฟซผู้ใช้แบบกราฟิกยังห่างไกลจากความสมบูรณ์แบบ แต่แนวทางที่ใช้ API หมายความว่าทุกอย่างสามารถอธิบายได้ด้วยสคริปต์ OpenShift แตกต่างจาก GUI อื่นๆ สำหรับ K8 ทำให้การเรียนรู้พื้นฐานของ Kubernetes ง่ายขึ้นมาก คุณไม่จำเป็นต้องได้รับปริญญา!
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
ฝูงนักเทียบท่า — Docker Swarm พยายามทำให้ K8 ง่ายขึ้นโดยกำจัดหลายสิ่งออกไป เหมาะสำหรับแอปพลิเคชันขนาดเล็ก แต่สำหรับแอปพลิเคชันระดับองค์กรกลับไม่ได้ผล นอกจากนี้ โซลูชัน เช่น AWS ECS ใช้แนวทางที่คล้ายกัน แต่ช่วยให้ทำงานกับบริการอื่นๆ ที่ฉันโต้ตอบด้วยได้ง่ายขึ้น (Lambda, IAM ฯลฯ)
เครื่องมือตรวจสอบ #1
ผู้ชนะ: ของที่ระลึกใหม่
New Relic รุ่นแรกๆ มีสิ่งหนึ่งที่ดี นั่นคือการตรวจสอบ APM (Application Performance Monitoring) ขณะนี้เป็นเครื่องมือตรวจสอบที่มีคุณสมบัติครบถ้วนซึ่งช่วยให้คุณสามารถตรวจสอบเซิร์ฟเวอร์ คอนเทนเนอร์ ประสิทธิภาพของฐานข้อมูล การตรวจสอบประสบการณ์ผู้ใช้ปลายทาง และแน่นอน การตรวจสอบประสิทธิภาพของแอปพลิเคชัน
ประโยชน์ที่สำคัญ
- ใช้งานง่าย - ตอนที่ฉันทำงานเป็นวิศวกรระบบ ฉันใช้เครื่องมือตรวจสอบมากมาย แต่ฉันไม่เคยพบเครื่องมือใดที่เรียบง่ายและใช้งานง่ายเท่ากับ New Relic เป็น SaaS คุณจึงไม่จำเป็นต้องติดตั้งด้วยตนเอง
- การมองเห็นตั้งแต่ต้นจนจบ - เครื่องมืออื่นๆ พยายามตรวจสอบองค์ประกอบเฉพาะของแอปพลิเคชันของคุณ ตัวอย่างเช่น ตัวชี้วัดการใช้งานโปรเซสเซอร์หรือการรับส่งข้อมูลเครือข่าย แต่ทั้งหมดนี้ต้องได้รับการตรวจสอบอย่างครอบคลุมเพื่อให้แอปพลิเคชันทำงานได้อย่างถูกต้อง New Relic ช่วยให้คุณสามารถรวบรวมข้อมูลทั้งหมดของคุณเข้าด้วยกันเพื่อรับมุมมองที่ครอบคลุมของสิ่งที่เกิดขึ้น
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
Zabbix — ระบบการตรวจสอบระบบแรกและเป็นที่ชื่นชอบของฉัน แต่ยังคงอยู่ในอดีตเนื่องจากขาดการพัฒนาในเทคโนโลยีคลาวด์และในด้านการตรวจสอบประสิทธิภาพของแอปพลิเคชัน APM Zabbix ยังคงตรวจสอบโครงสร้างพื้นฐานเซิร์ฟเวอร์แบบดั้งเดิมได้ดี แต่ก็แค่นั้นแหละ
ดาต้าด็อก — ให้ความสำคัญกับกระบวนการจัดการสภาพแวดล้อมการใช้งานจริงของแอปพลิเคชันมากเกินไป ไม่ใช่อยู่ที่ตัวโค้ดเอง ด้วยทีม DevOps ที่เกี่ยวข้องกับนักพัฒนา เราไม่จำเป็นต้องพึ่งพาเครื่องมือที่ยากต่อการใช้งานเพื่อให้การสนับสนุนที่ยอดเยี่ยม
เครื่องมือบันทึก #1
ผู้ชนะ: Splunk
มันยากที่จะแข่งขันกับ Splunk! เขายังคงเป็นผู้นำด้านการตัดไม้มาเป็นเวลานานและยังคงทำผลงานได้ดีกว่าใครๆ ด้วยข้อเสนอภายในองค์กรและ SaaS คุณสามารถใช้ Splunk ได้ทุกที่ ข้อเสียใหญ่คือราคา: Splunk ยังคงมีราคาแพงมาก!
ประโยชน์ที่สำคัญ
- ความแพร่หลาย - ธุรกิจต่างชื่นชอบ Splunk และบริษัทต่างๆ ก็มีเงินที่จะซื้อมัน
- แม้ว่าสตาร์ทอัพจะพยายามชดใช้ต้นทุน แต่ฟังก์ชันหลายอย่างสามารถแก้ไขได้ด้วยแอนะล็อกแบบโอเพ่นซอร์ส
- การบำรุงรักษา - พูดง่ายๆ ก็คือ Splunk ทำงานได้ดีและทำงานได้ดี มาพร้อมกับการตั้งค่าเริ่มต้นและคุณสมบัติมากมายที่พร้อมใช้งาน ไม่จำเป็นต้องเสียเวลาอ่านเอกสารและพยายามให้ Splunk ทำงานหรือถอดรหัสอะไรเลย
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
ELK Stack (ElasticSearch, LogStash และ Kibana) “เครื่องมือเหล่านี้ดูเหมือนจะเป็นรายการโปรดเพราะคุณไม่จำเป็นต้องขายตับเพื่อใช้มันด้วยซ้ำ” อย่างไรก็ตาม เมื่อชุดบันทึกเพิ่มมากขึ้นและจำนวนแอปพลิเคชันบนเครื่องเพิ่มขึ้น งานก็จะยากขึ้นเรื่อยๆ เมื่อเปรียบเทียบกับ Splunk แล้ว ด้วย ELK Stack ฉันใช้เวลาในการตั้งค่าเครื่องมือมากขึ้นก่อนที่จะสร้างแดชบอร์ดมากกว่าที่เคยมีมา
เครื่องมือการทำงานร่วมกัน
DevOps นั้นเกี่ยวกับการเปลี่ยนแปลงวัฒนธรรมภายในองค์กรเป็นหลัก การซื้อเครื่องมือใดๆ จะไม่เปลี่ยนแปลงแนวทางปฏิบัติในปัจจุบันในชั่วข้ามคืน แต่สามารถส่งเสริมการทำงานร่วมกันและวิธีการโต้ตอบใหม่ๆ ได้อย่างแน่นอน
หมวดหมู่ย่อยของเครื่องมือการทำงานร่วมกัน:
- ติดตามงาน
- ChatOps
- เอกสาร
เครื่องมือติดตามปัญหา #1
ผู้ชนะ: จิระ
จิรายังคงรักษาตำแหน่งผู้นำ แม้ว่าการแข่งขันในด้านนี้จะเพิ่มขึ้นก็ตาม ความยืดหยุ่นอันน่าทึ่งของ Jira ช่วยให้ทีมพัฒนาและบำรุงรักษาสามารถจัดการงานโครงการและงานเร่งด่วนได้ มาตรฐานในตัวที่ใช้คำศัพท์แบบ Agile ช่วยให้เปลี่ยนจากวิธีการทำงานแบบเดิมไปสู่กระบวนการที่มีประสิทธิภาพมากขึ้นได้ง่ายขึ้น
ประโยชน์ที่สำคัญ
- ความนิยม - เช่นเดียวกับเครื่องมืออื่น ๆ จิราถูกใช้เกือบทุกที่ ทีมขนาดเล็กใช้เวอร์ชันที่ถูกกว่าและเข้าถึงได้ง่ายกว่า และได้รับทุกสิ่งที่ต้องการ ในขณะที่บริษัทขนาดใหญ่สามารถซื้อใบอนุญาตที่มีราคาแพงกว่าได้
- บูรณาการ - จิราเป็นผู้บุกเบิกในสาขาของตน ข้อเท็จจริงนี้และการพัฒนาอย่างรวดเร็วของผลิตภัณฑ์นำไปสู่ความจริงที่ว่าบริษัทอื่นๆ เลือก Jira เพื่อสร้างการบูรณาการของตนเอง ซึ่งจะเป็นการเพิ่มมูลค่าของเครื่องมือ เราสามารถรวม Jira เข้ากับเครื่องมือทั้งหมดที่ระบุไว้ในบทความนี้ได้ทันทีพร้อมการกำหนดค่าเพียงเล็กน้อย
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
Trello — Trello ได้รับความนิยมอย่างรวดเร็วด้วยเครื่องมือ Kanban ฟรี อย่างไรก็ตาม เมื่อกระบวนการขยายขนาดและคุณเปลี่ยนจากงานหลายสิบงานเป็นพันงาน Trello จะกลายเป็นเรื่องยากที่จะนำทาง ค้นหา และรายงาน
Pivotal Tracker — ฉันเป็นแฟนตัวยงของเครื่องมือนี้เมื่อฉันทำงานให้กับสตาร์ทอัพ อย่างไรก็ตาม Pivotal Tracker ให้ความสำคัญกับการจัดการผลิตภัณฑ์มากกว่างานด้านเทคนิค แม้ว่าการจัดการผลิตภัณฑ์ใน Jira จะซับซ้อนกว่าเล็กน้อย แต่ก็ยังสามารถนำไปใช้ที่นั่นได้โดยไม่ต้องใช้เครื่องมือเพิ่มเติม
เครื่องมือ ChatOps #1
ผู้ชนะ: MatterMost
คำอธิบาย: บางทีสิ่งที่น่าประหลาดใจที่สุดสำหรับคุณในการเลือกของฉัน และนั่นเป็นข่าวดี! MatterMost ได้รับความนิยมจากการดึงเอาสิ่งที่ดีที่สุดจากเครื่องมือรุ่นก่อนๆ มาใช้งานในองค์กร สิ่งนี้สำคัญมากสำหรับบริษัทต่างๆ: MatterMost ช่วยให้คุณสามารถควบคุมข้อมูลของคุณและยังช่วยให้คุณรวมเข้ากับเครื่องมือที่ทำงานในเครื่องได้อีกด้วย เราไม่จำเป็นต้องออกไปนอกไฟร์วอลล์เพื่อตรวจสอบแชทที่ทำงานอีกต่อไป
ประโยชน์ที่สำคัญ
- โอเพ่นซอร์ส – MatterMost เวอร์ชันโอเพ่นซอร์สใช้งานได้ดีสำหรับทั้งทีมขนาดกลางและขนาดใหญ่ ต่างจากแผนบริการฟรีของ Slack ซึ่งจะลบประวัติข้อความของคุณ การใช้เซิร์ฟเวอร์ของคุณเองหมายความว่าคุณจะเก็บข้อมูลทั้งหมดไว้
- การรวมระบบ - เนื่องจาก API นั้นใช้ Slack API เกือบ 100% ดังนั้นการผสานรวม Slack เกือบทั้งหมดจึงสามารถใช้กับ MatterMost ได้โดยตรง
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
หย่อน — Slack นั้นเจ๋งมาก แต่คนพวกนี้เติบโตขึ้นมากจนเริ่มมองหาผลกำไร ขั้นตอนการคืนทุนของธุรกิจกำลังใกล้เข้ามา ซึ่งจะทำให้คุณค่าหลักหายไป: Slack ให้บริการฟรี; ข้อเสียที่สำคัญที่สุดของเวอร์ชันฟรีคือการลบประวัติการแชท
ทีมไมโครซอฟท์ — ลองรวมผลิตภัณฑ์ Microsoft เข้ากับผลิตภัณฑ์ที่ไม่ใช่ของ Microsoft... โชคดี! นั่นคือทั้งหมดที่ฉันต้องพูดเกี่ยวกับเครื่องมือนี้!
เครื่องมือเอกสาร #1
ผู้ชนะ: ที่บรรจบกัน
การสร้างและรักษาเอกสารทางเทคนิคที่มีคุณภาพเป็นกระบวนการที่ซับซ้อน ไม่ว่าคุณจะใช้เครื่องมือใดก็ตาม แม้ว่าเครื่องมือเอกสาร SaaS จำนวนมากจะออกสู่ตลาดเมื่อเร็วๆ นี้ แต่ฉันพบว่าเป็นเรื่องยากที่จะจ้างบุคคลภายนอกในการจัดเก็บเอกสารทางเทคนิคเกี่ยวกับแอปพลิเคชันที่สำคัญต่อภารกิจให้กับบุคคลที่สาม เป็นการดีกว่าที่จะจัดเก็บข้อมูลและเอกสารภายในองค์กร และนี่คือวิธีที่ Confluence แก้ปัญหาดังกล่าว
ประโยชน์ที่สำคัญ
- ใช้งานง่าย - เครื่องมือแบบสแตนด์อโลนส่วนใหญ่อาจซับซ้อนเล็กน้อยในการตั้งค่าและใช้งาน และต้องใช้ความรู้บางประการในการบำรุงรักษา Confluence Server ใช้งานได้ดีตั้งแต่แกะกล่องสำหรับผู้ใช้ 10 หรือ 10,000 ราย
- ปลั๊กอิน - ขอชื่นชมการบรรจบกันที่มีการนำทางที่สวยงามและใช้งานง่ายนอกกรอบ และความสามารถในการเพิ่มปลั๊กอินสำหรับเกือบทุกอย่างจะปลดล็อกศักยภาพที่คล้ายกับ Wiki
สินค้า
เข้าร่วมการต่อสู้แต่ไม่ชนะ
อ่านเอกสาร — เจ๋งสำหรับโอเพ่นซอร์ส แต่อย่าคิดที่จะเก็บความรู้ที่สำคัญไว้ที่นี่ด้วยซ้ำ
markdown - เหมาะสำหรับการบันทึกโค้ด แต่ยากต่อการโพสต์สถาปัตยกรรม กระบวนการ หรือเอกสารประเภทอื่นๆ เนื่องจากการจัดรูปแบบเฉพาะของ MarkDown
Jekyll — เมื่อบันทึกความรู้ด้านเทคนิค ฉันไม่ต้องการสร้างไซต์คงที่ใหม่ที่จะนำไปใช้ทุกครั้งที่มีการเปลี่ยนแปลง ระบบควบคุมเวอร์ชันที่เรียบง่ายของ Confluence ช่วยให้เอกสารภายในง่ายขึ้นอย่างมาก
สรุปผล
มีเครื่องมือ DevOps หลายร้อยรายการในตลาด ทำให้เป็นเรื่องยากที่จะทราบว่าควรใช้เครื่องมือใดและเมื่อใดควรนำไปใช้ ปฏิบัติตามคำแนะนำง่ายๆ นี้เพื่อเลือกเครื่องมือ DevOps สำหรับไปป์ไลน์ CI/CD ที่สมบูรณ์
อย่าลืมเลือกเครื่องมือจากทั้งห้าหมวดหมู่:
- การพัฒนาและสร้างเครื่องมือ
- ทดสอบเครื่องมืออัตโนมัติ
- เครื่องมือการปรับใช้
- เครื่องมือรันไทม์
- เครื่องมือการทำงานร่วมกัน
คำแนะนำหลัก: อัตโนมัติทุกอย่าง!
ขอบคุณแซค ชาปิโร!
ที่มา: will.com