ด้านการจัดการการวางจำหน่ายใดช่วยอธิบายความแตกต่างระหว่าง Waterfall และ Agile

เมื่ออธิบาย DevOps ให้ใครสักคนมันเกิดขึ้นว่าคำถามเกิดขึ้นเช่น:

การจัดการการเผยแพร่โดยใช้วิธีการ Agile แตกต่างจาก Waterfall อย่างไร

ดังนั้นเกณฑ์ใดบ้างที่คุณสามารถใช้อธิบายความแตกต่างเหล่านี้กับผู้ชมดังกล่าว

IMO DevOps เป็นวัฒนธรรมเหมือนกับ Agile (โดยไม่ต้องเลือกวิธีการที่คล่องตัว) ดังนั้นคุณไม่ต้อง "ทำ" DevOps

คุณ "ทำ" วิธีการเผยแพร่ที่เรียกว่าการจัดส่งแบบต่อเนื่องเป็นส่วนหนึ่งของวัฒนธรรม DevOps (การเปิดเผยแบบเต็มฉันไม่คิดว่าฉันเคยเรียกว่า CD เป็นวิธีการวางจำหน่ายมาก่อน แต่ในสถานะ jetlagged ของฉันฉันคิดว่ามันใช้งานได้)

ถ้าคุณจะซื้อนั้นแล้วนี่คือความหมายของการจัดส่งสินค้าอย่างต่อเนื่องจากที่หนึ่งของคนที่เขียนหนังสือโดยใช้ชื่อเดียวกันJez ฮัมเบิล

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

เป้าหมายของเราคือการปรับใช้ - ไม่ว่าจะเป็นระบบการกระจายขนาดใหญ่, สภาพแวดล้อมการผลิตที่ซับซ้อน, ระบบฝังตัวหรือแอป - คาดการณ์ได้, กิจวัตรประจำวันที่สามารถทำได้ตามความต้องการ

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

ดังนั้นคุณสามารถทำงานในระเบียบวิธีแบบ Agile โดยมีซอฟต์แวร์ที่คุณสามารถสาธิตให้กับธุรกิจทำให้แน่ใจว่าคุณกำลังทำการทดสอบอัตโนมัติที่เหมาะสมตอบสนองต่อการเปลี่ยนแปลงและทุกสิ่งที่ทำให้ดีกว่าน้ำตก ทั้งหมดนี้ไม่ได้หมายความว่าคุณสามารถนำไปใช้กับการผลิตได้จริง

คุณจะได้อะไรเช่นนี้:

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

สิ่งที่คุณต้องการจริงๆคือสิ่งที่มีลักษณะเช่นนี้มากขึ้น:

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

ห่า!? ฉันถามเกี่ยวกับ DevOps! ไม่มีใครถามเกี่ยวกับการจัดส่งอย่างต่อเนื่อง !!

ดังนั้น DevOps เกี่ยวข้องกับเรื่องนี้อย่างไร

มันยากมาก (เข้าใกล้ที่เป็นไปไม่ได้) ในการมีซอฟต์แวร์ของคุณอย่างแท้จริงในสถานะที่คุณสามารถปรับใช้เมื่อใดก็ตามที่คุณต้องการยกเว้นว่าทีมนั้นทำงานในวัฒนธรรม DevOps วัฒนธรรมที่ผู้ดูแลระบบ, DBA, SREs, เจ้าหน้าที่รักษาความปลอดภัย, Devs, QAs ฯลฯ เป็นส่วนหนึ่งของทีมเดียวและไม่ได้เป็นส่วนหนึ่งขององค์กรที่มีการโอนเงิน

หมายเหตุ :

ส่วนหนึ่งของความคิดเห็นที่โพสต์ไว้ในคำตอบนี้ซึ่งเป็นเช่นนั้น:

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

ฉันรักคำถามนั้น (เป็นตัวหนาในราคาข้างต้น)! แนวคิดของ "พร้อมหรือยัง?" เป็นสิ่งที่ฉันพูดจาโผงผางเกี่ยวกับตลอดเวลา - บล็อก IMO เป็นสิ่งสำคัญที่คุณต้องมั่นใจในความปลอดภัยประสิทธิภาพและการทดสอบอื่น ๆ บ่อยเกินไป "รอง" เพื่อฝึกฝนซีดี คุณสมบัติจะเสร็จสิ้นเมื่อเสร็จสิ้น แต่แฮกเกอร์มักจะอยู่ที่นั่นเสมอ

ไม่แน่ใจว่าไม่มีคนอื่นหรือเปล่า แต่นี่เป็นเกณฑ์ที่ฉันใช้:

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

และถ้าคุณต้องการสัมผัสกับความแตกต่างของตัวคุณเองในฐานะผู้ใช้ซอฟต์แวร์บางตัวลองนึกถึงการใช้ซอฟต์แวร์บางตัว (เช่นการกระจาย Linux) ซึ่งคุณมีตัวเลือกระหว่างการใช้งานรุ่นใดรุ่นหนึ่ง:

• a " Rolling" release (==> Agile)

• เป็น " Long Term Support" ปล่อย (==> น้ำตก)