แนวทางปฏิบัติที่อธิบายถึง DevOps เช่นการส่งมอบอย่างต่อเนื่องการดำเนินการอัตโนมัติและอื่น ๆ ที่เกี่ยวข้องกับผลิตภัณฑ์ที่ให้บริการอย่างต่อเนื่องเช่นผลิตภัณฑ์ SaaS
ตัวอย่างเช่น บริษัท พัฒนาซอฟต์แวร์ที่ส่วนใหญ่ทำโครงการสำหรับลูกค้ารายอื่นอาจไม่สามารถดูแลสิ่งเหล่านี้ได้หลังจากโครงการเสร็จสิ้น และโครงการของลูกค้าจะไม่ถูกแชร์กับลูกค้ารายอื่นเพราะไม่เกี่ยวข้อง
DevOps ใช้กับ บริษัท ที่พัฒนาหลายโครงการที่เป็นแบบครั้งเดียวหรือไม่? สิ่งใดที่ใช้กับ DevOps ในกรณีนี้ถ้าทั้งหมด?
คำตอบ:
ไม่ได้อย่างแน่นอน!
DevOps คือการทำลายไซโลแบบดั้งเดิม (แผนก) เพื่อให้มีประสิทธิภาพมากขึ้น
การสื่อสารที่ดีขึ้นระหว่างทีมการมองเห็นที่ดีขึ้นและกระบวนการที่เชื่อถือได้และอัตโนมัติเป็นวิธีที่ทำให้ผลิตภัณฑ์ดีขึ้น
ฉันเคยทำงานให้กับ บริษัท สื่อขนาดใหญ่ที่เราจะสนับสนุนเครื่องมือภายในและพัฒนาเว็บไซต์สาธารณะ
ประโยชน์ของ DevOps ในกรณีของเรามีดังต่อไปนี้:
โดยรวมแล้วฉันจะบอกว่าไม่ว่าคุณจะปรับปรุงสภาพแวดล้อมการผลิตของคุณวันละครั้งหรือหนึ่งครั้งต่อเดือนและไม่ว่าคุณมีลูกค้าหรือโมเดลธุรกิจของคุณกี่องค์กรทุกองค์กรสามารถใช้การสื่อสารที่ดีกว่าเครื่องมือที่ดีกว่า เป็นต้น
ทีมของฉันและฉันมีหน้าที่รับผิดชอบในการพัฒนา "one-offs" ผลิตภัณฑ์ที่เมื่อเสร็จแล้วจะมอบให้กับลูกค้าสำหรับการบำรุงรักษาหรือในบางกรณีมีการจัดการโดยเราโดยมีค่าธรรมเนียม
เรายังคงต้องรักษาขั้นตอนการพัฒนาที่แข็งแกร่งเพื่อจัดการข้อเสนอแนะอย่างต่อเนื่องจากลูกค้าของเราเพื่อให้แน่ใจว่าเราจัดส่งสิ่งที่พวกเขาเชื่อถือได้และพิสูจน์ให้ทำงาน
ในขณะที่ลูกค้าไม่สนใจ DevOps (ในกรณีส่วนใหญ่) แต่ก็ยังมีประโยชน์สำหรับเรา ด้วย DevOps เราสามารถผลักดันงานสร้างใหม่ได้อย่างรวดเร็วดังนั้นลูกค้าสามารถดูข้อเสนอแนะในไม่กี่นาทีและเรายังสามารถตรวจจับข้อผิดพลาด / ข้อบกพร่องด้วยการทดสอบของเราผ่าน Jenkins / Travis
เพื่อให้มั่นใจว่ากลยุทธ์การปรับใช้ของเราเหมือนกันในทุกโครงการเรามุ่งเน้นการจัดคอนเทนเนอร์แอปพลิเคชันของเรา การใช้นักเทียบท่าเราสามารถมอบแอปพลิเคชันให้กับลูกค้าของเราได้อย่างง่ายดาย
ต้นทุนที่ประหยัดได้โดย DevOps นั้นยากที่จะกำหนด เรามีค่าใช้จ่ายเพิ่มเติมในรูปแบบของซอฟต์แวร์ที่เราเลือกใช้สำหรับท่อ (Travis, Jenkins, Puppet, คุณมีอะไร) แต่เรายังประหยัดเวลาและเงินด้วยการแก้ไขข้อบกพร่อง / ให้ข้อเสนอแนะกับลูกค้าได้อย่างรวดเร็ว เวลาตอบสนองที่รวดเร็วของเราทำให้ลูกค้าของเรามีความสุขในทางกลับกันทำให้กระเป๋าของเรามีความสุข
ฉันทำงานให้กับ บริษัท ที่ผลิตซอฟต์แวร์เป็นผลิตภัณฑ์ที่ย่อขนาดติดตั้งอย่างสมบูรณ์และรองรับการปรับใช้และเป็นรหัสฝังตัวในอุปกรณ์ ในทุก บริษัท นั้น DevOps ให้การสนับสนุนที่จำเป็นสำหรับการพัฒนา:
ในทุกกรณีสิ่งเหล่านี้เป็นสิ่งที่ผู้พัฒนาแต่ละคนสามารถทำได้เหมือนเป็นการใช้ครั้งเดียว แต่นั่นจะไม่เป็นการใช้เวลาของนักพัฒนาซอฟต์แวร์ได้อย่างดีและไม่มีการรับประกันการควบคุมการกำหนดค่าที่เหมือนกันกับการสร้างอัตโนมัติ
กิจกรรมที่เกี่ยวกับการพัฒนาและการดำเนินงานของซอฟต์แวร์ก่อนหน้านี้ไม่จำเป็นต้องบูรณาการระหว่างแผนก แต่สำหรับวันนี้มีความจำเป็นที่จะต้องร่วมมืออย่างใกล้ชิดกับทุกแผนก (การพัฒนาการดำเนินงานด้านไอทีการประกันคุณภาพ ฯลฯ )
สำหรับนักพัฒนาการเปลี่ยนแปลงคือสิ่งที่พวกเขาได้รับเงิน ธุรกิจต้องการการเปลี่ยนแปลงเสมอเพื่อให้เข้ากับโลกสมัยใหม่ ความเข้าใจนี้ผลักดันให้นักพัฒนาสร้างจำนวนการเปลี่ยนแปลงที่เป็นไปได้สูงสุด ผู้เชี่ยวชาญด้านไอทีมีความเข้าใจที่แตกต่างกันซึ่งการเปลี่ยนแปลงเป็นอันตราย แต่ละคนคิดว่ามันทำงานได้อย่างถูกต้องและเป็นประโยชน์ต่อธุรกิจ แน่นอนถ้าเราพิจารณาแยกพวกเขาพวกเขาทั้งคู่ถูกต้อง
พนักงานทุกคนต้องเข้าใจว่าพวกเขาเป็นส่วนหนึ่งของกระบวนการเดียว DevOps ปลูกฝังความคิดซึ่งทำให้เป็นไปได้ที่จะตระหนักว่าการตัดสินใจส่วนตัวและการกระทำของทุกคนควรถูกนำไปสู่การตระหนักถึงเป้าหมายเดียว และควรวัดความสำเร็จเมื่อเทียบกับวงจรการพัฒนาสู่การส่งมอบทั้งหมดไม่ใช่จากความสำเร็จของแต่ละบทบาท จากความร่วมมืออย่างใกล้ชิดระหว่างผู้พัฒนาและผู้เชี่ยวชาญด้านการบำรุงรักษาจึงเกิดวิศวกรรุ่นใหม่ขึ้นมาซึ่งนำความสำเร็จที่ดีที่สุดของทั้งสองสาขาวิชามารวมเข้าด้วยกันเพื่อประโยชน์ของผู้ใช้ สิ่งนี้แสดงให้เห็นในลักษณะของทีมข้ามสายงานที่มีประสบการณ์ในการพัฒนาการจัดการการกำหนดค่าการจัดการฐานข้อมูลการทดสอบและการจัดการโครงสร้างพื้นฐาน
ดังนั้นวิธีการนี้มีประโยชน์ไม่เพียง แต่ใน SaaS เท่านั้น
ไม่ใช่เลย. แม้ว่าจะมีตัวอย่างที่ดีอยู่แล้วในกระทู้นี้ แต่ฉันต้องการแบ่งปันเรื่องเล็ก ๆ น้อย ๆ ของฉันเอง ในปี 2544 ฉันได้รับโครงการซอฟต์แวร์ด้วยการเปิดตัวที่เกี่ยวข้องกับการสร้างซีดี เอกสารประกอบสำหรับกระบวนการวางจำหน่ายประกอบด้วยขั้นตอน 40 (!) ที่บันทึกโดยวิศวกรก่อนหน้าซึ่งมีคำแนะนำที่เขียนด้วยมือบางอย่างเช่น "เปิดไฟล์กำหนดค่านี้และเปลี่ยนชื่อของไฟล์. jar ในบรรทัดที่ 41 เพื่อรวมหมายเลขเวอร์ชันของ การเปิดตัวใหม่ "
เราอัตโนมัติแบบอัตโนมัติทุกขั้นตอนของกระบวนการสร้างนั้นแทนที่คำสั่งที่เขียนด้วยมือเช่นนั้นด้วยสิ่งต่าง ๆ เช่น 'แพทช์' ที่เขียนด้วยสคริปต์ เราต้องเปิดตั๋วกับผู้จำหน่ายเครื่องมือติดตั้งของ บริษัท อื่นเพื่อให้สามารถแก้ไขไฟล์โครงการได้
เมื่อกระบวนการนั้นเป็นไปโดยอัตโนมัติเราก็ซื้อ 'CD Jukebox' ทุกคืนหลังจากการทดสอบจะผ่านเครื่องสร้างจะสร้างซีดีติดตั้งใหม่โดยอัตโนมัติ ผู้ทดสอบของเราสามารถเข้ามาในเช้าวันรุ่งขึ้นคว้าดิสก์และตรวจสอบให้แน่ใจว่าทุกอย่างสามารถติดตั้งได้
แน่นอนว่าเรามีลูปข้อเสนอแนะที่เข้มงวดมากขึ้นเมื่อเราสามารถปรับใช้ซอฟต์แวร์เป็นบริการได้ แต่หลักการหลักของระบบอัตโนมัติ, ข้อเสนอแนะ, รอบเวลา, การเปิดตัวขนาดเล็ก ฯลฯ ล้วนมีผล