ทำงานเร็วขึ้นด้วยการส่งมอบอย่างต่อเนื่อง

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

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

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

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

ความถูกต้องของการติดตั้งใช้จริง: การทดสอบการติดตั้งใช้จริงในรูปแบบที่พื้นฐานที่สุดจะทำให้ชิ้นงานที่เพิ่งนำไปติดตั้งใช้จริงสามารถเริ่มทำงานและตอบสนองต่องานได้ โดยที่เป็นส่วนหนึ่งของลำดับการทำงานหลังการติดตั้งใช้จริง เราทำการตรวจโดยเร็วซึ่งทำให้แน่ใจได้ว่าชิ้นงานที่เพิ่งติดตั้งใช้จริงนั้นเริ่มทำงานแล้วและกำลังให้บริการปริมาณงาน ตัวอย่างเช่น เราใช้ฮุกเหตุการณ์วงจรชีวิตในไฟล์ AWS CodeDeploy AppSpec เพื่อสั่งการสคริปต์ง่ายๆ ให้หยุด เริ่ม และตรวจสอบความถูกต้องของการติดตั้งใช้จริง เรายังตรวจดูด้วยว่าเรามีสมรรถภาพเพียงพอในการตอบสนองปริมาณงานของลูกค้า เราได้สร้างเทคนิคอย่างเช่น โฮสต์ที่มีสภาพดีขั้นต่ำใน CodeDeploy เพื่อตรวจสอบว่าเรามีสมรรถภาพที่เพียงพอในการตอบสนองลูกค้าของเราเสมอ สุดท้าย หากกลไกการติดตั้งใช้จริงสามารถตรวจพบความล้มเหลว ก็ควรจะย้อนกลับการเปลี่ยนแปลงนั้น เพื่อลดเวลาที่ลูกค้าจะเห็นข้อบกพร่อง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เดินหน้าอย่างรวดเร็วมาจนถึงวันนี้ ปัจจุบัน Amazon อยู่ในจุดที่ทีมงานต่างๆ ตั้งเป้าไปที่การทำงานอัตโนมัติโดยสมบูรณ์ เมื่อเขียนโค้ดใหม่ สำหรับเรา การทำงานอัตโนมัติเป็นวิธีเดียวที่เราสามารถขยายธุรกิจของเราได้ต่อไป