เรามาพูดคุยกันว่าเหตุใดเครื่องมือ CI และ CI จึงแตกต่างกันโดยสิ้นเชิง
ความเจ็บปวดที่ CI มีจุดมุ่งหมายเพื่อแก้ไข แนวคิดนี้มาจากไหน คำยืนยันล่าสุดว่าได้ผล จะเข้าใจได้อย่างไรว่าคุณมีการฝึกฝน ไม่ใช่แค่ติดตั้ง Jenkins
ไอเดียการทำรายงานเรื่อง Continuous Integration โผล่มาเมื่อปีก่อนตอนที่ผมไปสัมภาษณ์และหางานทำ ฉันได้พูดคุยกับบริษัท 10-15 แห่ง มีเพียงบริษัทเดียวเท่านั้นที่สามารถตอบได้อย่างชัดเจนว่า CI คืออะไร และอธิบายว่าพวกเขาตระหนักได้อย่างไรว่าพวกเขาไม่มีมัน ที่เหลือกำลังพูดถึงเจนกินส์เรื่องไร้สาระที่ไม่สามารถเข้าใจได้ :) เรามีเจนกินส์มันสร้าง CI! ในระหว่างรายงาน ฉันจะพยายามอธิบายว่าจริงๆ แล้วการบูรณาการอย่างต่อเนื่องคืออะไร และเหตุใด Jenkins และเครื่องมือที่คล้ายกันจึงมีความสัมพันธ์ที่อ่อนแอมากกับสิ่งนี้
แล้วคุณมักจะนึกถึงอะไรเมื่อคุณได้ยินคำว่า CI? คนส่วนใหญ่จะนึกถึง Jenkins, Gitlab CI, Travis ฯลฯ
แม้ว่าเราจะ google มัน มันก็จะให้เครื่องมือเหล่านี้แก่เรา
หากคุณคุ้นเคยกับการถาม ทันทีหลังจากแสดงรายการเครื่องมือ พวกเขาจะบอกคุณว่า CI คือเมื่อคุณสร้างและรันการทดสอบใน Pull Request สำหรับการคอมมิต
การบูรณาการอย่างต่อเนื่องไม่เกี่ยวกับเครื่องมือ ไม่เกี่ยวกับแอสเซมบลีที่มีการทดสอบในสาขา! การบูรณาการอย่างต่อเนื่องคือการฝึกฝนการรวมโค้ดใหม่บ่อยครั้งมาก และการใช้มันนั้นไม่จำเป็นเลยที่จะต้องกั้นรั้ว Jenkins, GitLab ฯลฯ
ก่อนที่เราจะรู้ว่า CI ที่มีคุณสมบัติครบถ้วนนั้นเป็นอย่างไร เรามาเจาะลึกบริบทของผู้ที่คิดไอเดียนี้และสัมผัสถึงความเจ็บปวดที่พวกเขาพยายามแก้ไขกันก่อน
และพวกเขาก็แก้ไขความเจ็บปวดจากการทำงานร่วมกันเป็นทีม!
มาดูตัวอย่างความยากลำบากที่นักพัฒนาเผชิญเมื่อพัฒนาในทีมกัน ที่นี่เรามีโปรเจ็กต์ สาขาหลักใน git และนักพัฒนาสองคน
และพวกเขาก็ไปทำงานตามที่ทุกคนคุ้นเคยมานานแล้ว เรารับงานในรูปแบบที่ยิ่งใหญ่ สร้างสาขาฟีเจอร์ และเขียนโค้ด
คนหนึ่งเสร็จสิ้นฟีเจอร์เร็วขึ้นและรวมเข้ากับมาสเตอร์
อันที่สองต้องใช้เวลามากกว่านี้ มันมารวมกันในภายหลังและจบลงด้วยความขัดแย้ง ตอนนี้ แทนที่จะเขียนฟีเจอร์ที่ธุรกิจต้องการ นักพัฒนาใช้เวลาและพลังงานในการแก้ไขข้อขัดแย้ง
ยิ่งการรวมฟีเจอร์ของคุณเข้ากับมาสเตอร์ทั่วไปยากขึ้นเท่าไร เราก็ยิ่งใช้เวลาไปกับมันมากขึ้นเท่านั้น และผมแสดงสิ่งนี้ด้วยตัวอย่างที่ค่อนข้างง่าย นี่คือตัวอย่างที่มี Developer เพียง 2 คน ลองนึกภาพว่ามีคน 10 หรือ 15 หรือ 100 คนในบริษัทเขียนข้อมูลลงใน Repository เดียว คุณจะคลั่งไคล้เพื่อแก้ไขข้อขัดแย้งเหล่านี้ทั้งหมด
มีกรณีที่แตกต่างกันเล็กน้อย เรามีผู้เชี่ยวชาญและนักพัฒนาบางคนกำลังทำอะไรบางอย่าง
พวกเขาสร้างกิ่งไม้
คนหนึ่งเสียชีวิต ทุกอย่างเรียบร้อยดี เขาผ่านภารกิจนี้ไป
นักพัฒนาคนที่สองก็ส่งมอบงานของเขา สมมุติว่าเขาส่งไปตรวจสอบ บริษัทหลายแห่งมีแนวปฏิบัติที่เรียกว่าการทบทวน ประการหนึ่ง การปฏิบัตินี้ดีและมีประโยชน์ ในทางกลับกัน มันทำให้เราช้าลงในหลายๆ ด้าน เราจะไม่พูดถึงเรื่องนั้น แต่นี่คือตัวอย่างที่ดีว่าเรื่องราวบทวิจารณ์ที่ไม่ดีสามารถนำไปสู่อะไรได้ คุณได้ส่งคำขอดึงเพื่อตรวจสอบ ไม่มีอะไรให้นักพัฒนาทำอีกต่อไป เขาเริ่มทำอะไร? เขาเริ่มไปทำงานอื่น
ในช่วงเวลานี้ นักพัฒนาคนที่สองได้ทำอย่างอื่น
คนแรกเสร็จสิ้นภารกิจที่สาม
และหลังจากผ่านไประยะหนึ่ง บทวิจารณ์ของเขาก็ได้รับการทดสอบ และเขากำลังพยายามที่จะตกลงใจ แล้วเกิดอะไรขึ้น? มันจับข้อขัดแย้งจำนวนมาก ทำไม เนื่องจากในขณะที่คำขอดึงของเขาค้างอยู่ในการตรวจสอบ มีหลายสิ่งที่เปลี่ยนแปลงไปแล้วในโค้ด
นอกจากเรื่องที่มีความขัดแย้งแล้วยังมีเรื่องที่มีการสื่อสาร ในขณะที่เธรดของคุณค้างอยู่ในการตรวจสอบ ในขณะที่กำลังรอบางสิ่งบางอย่าง ในขณะที่คุณกำลังทำงานกับฟีเจอร์มาเป็นเวลานาน คุณจะหยุดติดตามสิ่งอื่นที่เปลี่ยนแปลงในฐานโค้ดของบริการของคุณ บางทีสิ่งที่คุณพยายามแก้ไขตอนนี้อาจแก้ไขไปแล้วเมื่อวานนี้ และคุณสามารถใช้วิธีบางอย่างและนำมันกลับมาใช้ใหม่ได้ แต่คุณจะไม่เห็นสิ่งนี้เพราะคุณทำงานกับสาขาที่ล้าสมัยอยู่เสมอ และสาขาที่ล้าสมัยนี้ส่งผลให้คุณต้องแก้ไขข้อขัดแย้งในการรวมเสมอ
ปรากฎว่าถ้าเราทำงานเป็นทีม กล่าวคือ ไม่ใช่ใครคนหนึ่งกำลังยุ่งอยู่ใน Repository แต่มีคน 5-10 คน ยิ่งเราไม่เพิ่มโค้ดของเราใน Master นานเท่าไหร่ เราก็ยิ่งต้องทนทุกข์ทรมานมากขึ้นเพราะท้ายที่สุดแล้วเราต้องการ บางสิ่งบางอย่างแล้วรวมมันเข้าด้วยกัน และยิ่งเรามีข้อขัดแย้งมากขึ้นและยิ่งเราทำงานร่วมกับเวอร์ชันเก่ามากเท่าใด ปัญหาก็ยิ่งมากขึ้นเท่านั้น
ทำอะไรด้วยกันก็เจ็บ! เรามักจะขวางทางกันอยู่เสมอ
ปัญหานี้ถูกสังเกตเห็นเมื่อ 20 กว่าปีที่แล้ว ฉันพบการกล่าวถึงครั้งแรกเกี่ยวกับการฝึกบูรณาการอย่างต่อเนื่องใน Extreme Programming
Extreme Programming เป็นเฟรมเวิร์กแบบ Agile แรก หน้านี้ปรากฏในปี 96 และแนวคิดก็คือการใช้แนวทางปฏิบัติในการเขียนโปรแกรม การวางแผน และสิ่งอื่นๆ เพื่อให้การพัฒนามีความยืดหยุ่นมากที่สุดเท่าที่จะเป็นไปได้ เพื่อให้เราสามารถตอบสนองต่อการเปลี่ยนแปลงหรือข้อกำหนดจากลูกค้าของเราได้อย่างรวดเร็ว และพวกเขาเริ่มเผชิญกับสิ่งนี้เมื่อ 24 ปีที่แล้ว หากคุณทำอะไรบางอย่างเป็นเวลานานๆ และนอกสนาม คุณจะใช้เวลากับสิ่งนั้นมากขึ้นเพราะว่าคุณมีความขัดแย้ง
ตอนนี้เราจะวิเคราะห์วลี "การบูรณาการอย่างต่อเนื่อง" เป็นรายบุคคล หากเราแปลโดยตรง เราก็จะได้รับการบูรณาการอย่างต่อเนื่อง แต่ความต่อเนื่องนั้นไม่ชัดเจนมากนัก มันไม่ต่อเนื่องกันมาก แต่จะมีการบูรณาการมากน้อยเพียงใดก็ไม่ชัดเจนเช่นกัน
และนั่นคือเหตุผลว่าทำไมฉันถึงเสนอราคาจาก Extreme Programming ให้คุณตอนนี้ และเราจะวิเคราะห์ทั้งสองคำแยกกัน
บูรณาการ - ตามที่ฉันได้กล่าวไปแล้ว เรามุ่งมั่นที่จะให้แน่ใจว่าวิศวกรทุกคนทำงานกับโค้ดเวอร์ชันล่าสุด เพื่อที่เขาจะพยายามเพิ่มโค้ดของเขาในสาขาทั่วไปให้บ่อยที่สุดเท่าที่จะเป็นไปได้ เพื่อให้เหล่านี้เป็นสาขาเล็กๆ เพราะหากมีขนาดใหญ่ เราก็อาจติดอยู่กับข้อขัดแย้งในการผสานได้อย่างง่ายดายเป็นเวลาหนึ่งสัปดาห์ โดยเฉพาะอย่างยิ่งหากเรามีวงจรการพัฒนาที่ยาวนาน เช่น Waterfall ซึ่งนักพัฒนาออกไปเป็นเวลาหนึ่งเดือนเพื่อตัดฟีเจอร์ขนาดใหญ่บางอย่างออก และเขาจะติดอยู่ในขั้นตอนการบูรณาการเป็นเวลานานมาก
การบูรณาการคือเมื่อเรานำสาขาของเราไปบูรณาการกับต้นแบบ เราก็จะรวมมันเข้าด้วยกัน มีตัวเลือกที่ดีที่สุดเมื่อเราเป็นนักพัฒนา transbase โดยที่เรามุ่งมั่นที่จะให้แน่ใจว่าเราจะเขียนถึงผู้เชี่ยวชาญทันทีโดยไม่มีสาขาเพิ่มเติมใดๆ
โดยทั่วไป การผสานรวมหมายถึงการนำโค้ดของคุณมาลากไปที่ต้นแบบ
คำว่า "ต่อเนื่อง" ในที่นี้หมายถึงอะไร สิ่งที่เรียกว่าความต่อเนื่อง? การปฏิบัติหมายความว่านักพัฒนาพยายามที่จะบูรณาการโค้ดของเขาโดยเร็วที่สุด นี่คือเป้าหมายของเขาเมื่อปฏิบัติงานใดๆ - เพื่อให้ได้โค้ดของเขาไปสู่ต้นแบบโดยเร็วที่สุด ในโลกอุดมคติ นักพัฒนาจะทำสิ่งนี้ทุกๆ สองสามชั่วโมง นั่นคือคุณนำปัญหาเล็ก ๆ มารวมเข้ากับต้นแบบ ทุกอย่างดีมาก นี่คือสิ่งที่คุณมุ่งมั่นเพื่อ และต้องทำอย่างต่อเนื่อง ทันทีที่คุณทำอะไรสักอย่าง คุณจะใส่มันเข้าไปในต้นแบบทันที
และนักพัฒนาที่ทำบางสิ่งบางอย่างต้องรับผิดชอบต่อสิ่งที่เขาทำเพื่อให้มันใช้งานได้และไม่ทำลายสิ่งใดๆ นี่คือจุดที่เรื่องราวการทดสอบมักจะออกมา เราต้องการทำการทดสอบบางอย่างกับคอมมิตของเราและการรวมของเรา เพื่อให้แน่ใจว่ามันจะได้ผล และนี่คือจุดที่เจนกินส์สามารถช่วยคุณได้
แต่สำหรับเรื่องราว: มาทำการเปลี่ยนแปลงเล็กๆ น้อยๆ กันเถอะ ปล่อยให้งานเล็กๆ กันเถอะ สร้างปัญหา และพยายามฝังมันลงในต้นแบบทันที - ไม่มีเจนกินส์คนใดที่จะช่วยได้ที่นี่ เพราะเจนกินส์จะช่วยคุณทำการทดสอบเท่านั้น
คุณสามารถทำได้โดยไม่มีพวกเขา สิ่งนี้จะไม่ทำร้ายคุณเลย เพราะเป้าหมายของการปฏิบัติคือการวัดผลให้บ่อยที่สุดเท่าที่จะทำได้ เพื่อไม่ให้เสียเวลากับข้อขัดแย้งใดๆ ในอนาคตมากนัก
ลองจินตนาการว่าด้วยเหตุผลบางอย่างเราอยู่ในปี 2020 โดยไม่มีอินเทอร์เน็ต และเราทำงานในท้องถิ่น เราไม่มีเจนกินส์ นี่เป็นเรื่องปกติ คุณยังสามารถสร้างสาขาในพื้นที่ต่อไปได้ คุณเขียนโค้ดบางอย่างลงไป เราทำงานเสร็จภายใน 3-4 ชั่วโมง เราเปลี่ยนมาใช้ master ทำ git pull และรวมสาขาของเราที่นั่น พร้อม. หากคุณทำเช่นนี้บ่อยครั้ง ยินดีด้วย คุณมีการบูรณาการอย่างต่อเนื่อง!
มีหลักฐานอะไรในโลกสมัยใหม่ที่แสดงว่าคุ้มค่ากับการใช้พลังงาน? เพราะโดยทั่วไปแล้วมันเป็นเรื่องยาก หากคุณพยายามทำงานแบบนี้ คุณจะเข้าใจว่าตอนนี้การวางแผนบางอย่างจะได้รับผลกระทบ คุณจะต้องทุ่มเทเวลามากขึ้นในการสลายตัวของงาน เพราะถ้าคุณทำมนุษย์... คุณจะไม่สามารถตกลงกันได้เร็วและจะมีปัญหาตามมา คุณจะไม่มีการฝึกฝนอีกต่อไป
และมันจะมีราคาแพง ตั้งแต่วันพรุ่งนี้จะไม่สามารถทำงานได้ทันทีโดยใช้การผสานรวมแบบต่อเนื่อง คุณจะใช้เวลานานมากในการทำความคุ้นเคย จะใช้เวลานานมากในการทำความคุ้นเคยกับการแยกย่อยงาน จะใช้เวลานานมากในการทำความคุ้นเคยกับการทำซ้ำแบบฝึกหัดถ้าคุณมี . เพราะเป้าหมายของเราคือให้มันละลายในวันนี้ และหากคุณทำการตรวจสอบภายในสามวัน แสดงว่าคุณประสบปัญหาและการบูรณาการอย่างต่อเนื่องไม่ได้ผลสำหรับคุณ
แต่ตอนนี้เรามีหลักฐานที่เกี่ยวข้องซึ่งบอกเราว่าการลงทุนในแนวทางปฏิบัตินี้สมเหตุสมผลหรือไม่?
สิ่งแรกที่ฉันนึกถึงคือ State of DevOps นี่คือการศึกษาที่พวกเขาทำมาเป็นเวลา 7 ปีแล้ว ตอนนี้พวกเขาทำในฐานะองค์กรอิสระ แต่อยู่ภายใต้ Google
และการศึกษาในปี 2018 ของพวกเขาแสดงให้เห็นความสัมพันธ์ระหว่างบริษัทที่พยายามใช้สาขาที่มีอายุสั้นซึ่งบูรณาการได้รวดเร็ว บูรณาการบ่อยครั้ง และมีตัวบ่งชี้ประสิทธิภาพไอทีที่ดีขึ้น
ตัวชี้วัดเหล่านี้คืออะไร? ตัวชี้วัด 4 ประการเหล่านี้นำมาจากทุกบริษัทในแบบสอบถาม ได้แก่ ความถี่ในการใช้งาน ระยะเวลาในการเปลี่ยนแปลง ระยะเวลาในการกู้คืนบริการ อัตราความล้มเหลวในการเปลี่ยนแปลง
และประการแรก มีความสัมพันธ์กันนี้ เรารู้ว่าบริษัทที่วัดผลมักจะมีตัวชี้วัดที่ดีกว่ามาก และพวกเขาแบ่งบริษัทออกเป็นหลายประเภท: บริษัทเหล่านี้เป็นบริษัทที่ช้าซึ่งผลิตบางสิ่งบางอย่างได้ช้า บริษัทที่มีผลงานปานกลาง บริษัทที่มีประสิทธิภาพสูง และบริษัทชั้นนำ พวกหัวกะทิคือ Netflix, Amazon ซึ่งเร็วสุดๆ ทำทุกอย่างได้อย่างรวดเร็ว สวยงาม และมีประสิทธิภาพ
เรื่องที่สองซึ่งเกิดขึ้นเมื่อเดือนที่แล้ว Technology Radar มีบทความดีๆ เกี่ยวกับ Gitflow Gitflow แตกต่างจากที่อื่นตรงที่กิ่งก้านของมันมีอายุยืนยาว มีกิ่งที่ออกจำหน่ายที่มีอายุยืนยาวและมีกิ่งก้านที่มีชีวิตอยู่ได้นานเช่นกัน แนวปฏิบัติที่ Technology Radar ได้ย้ายไปที่ HOLD ทำไม เพราะผู้คนต้องเผชิญกับความเจ็บปวดจากการบูรณาการ
หากสาขาของคุณอยู่ได้นานมาก มันจะติดขัด เน่าเปื่อย และเราเริ่มใช้เวลามากขึ้นในการพยายามเปลี่ยนแปลงบางอย่างกับมัน
และเมื่อเร็ว ๆ นี้ ผู้เขียน Gitflow กล่าวว่าหากเป้าหมายของคุณคือการบูรณาการอย่างต่อเนื่อง หากเป้าหมายของคุณคือคุณต้องการม้วนให้บ่อยที่สุดเท่าที่จะเป็นไปได้ Gitflow ก็เป็นความคิดที่ไม่ดี เขาเสริมแยกต่างหากในบทความว่า หากคุณมีแบ็กเอนด์ที่คุณสามารถต่อสู้เพื่อสิ่งนี้ได้ Gitflow ก็ไม่จำเป็นสำหรับคุณ เพราะ Gitflow จะทำให้คุณช้าลง Gitflow จะสร้างปัญหาให้คุณด้วยการบูรณาการ
นี่ไม่ได้หมายความว่า Gitflow ไม่ดีและไม่ควรใช้ มันสำหรับโอกาสอื่น ๆ ตัวอย่างเช่น เมื่อคุณต้องการรองรับบริการหรือแอปพลิเคชันหลายเวอร์ชัน เช่น ในกรณีที่คุณต้องการการสนับสนุนเป็นระยะเวลานาน
แต่ถ้าคุณพูดคุยกับผู้ที่สนับสนุนบริการดังกล่าว คุณจะได้ยินความเจ็บปวดมากมายเกี่ยวกับความจริงที่ว่าเวอร์ชันนี้คือ 3.2 ซึ่งเมื่อ 4 เดือนที่แล้ว แต่การแก้ไขนี้ไม่ได้รวมอยู่ในนั้น และตอนนี้เพื่อที่จะทำให้มัน คุณต้องทำการเปลี่ยนแปลงมากมาย และตอนนี้พวกเขาก็ติดขัดอีกครั้ง และตอนนี้พวกเขากำลังเล่นซออยู่เป็นเวลาหนึ่งสัปดาห์เพื่อพยายามใช้ฟีเจอร์ใหม่
ตามที่ Alexander Kovalev ระบุไว้อย่างถูกต้องในแชท ความสัมพันธ์ไม่เหมือนกับสาเหตุ นี่เป็นเรื่องจริง กล่าวคือ ไม่มีการเชื่อมโยงโดยตรงว่าถ้าคุณมีการบูรณาการอย่างต่อเนื่อง ตัวชี้วัดทั้งหมดก็จะดีมาก แต่มีความสัมพันธ์เชิงบวกว่าหากสิ่งหนึ่งเป็นหนึ่ง ก็มีแนวโน้มว่าอีกสิ่งหนึ่งก็จะเป็นเช่นนั้นเช่นกัน ไม่ใช่ข้อเท็จจริง แต่มีแนวโน้มมากที่สุด มันเป็นเพียงความสัมพันธ์
ดูเหมือนว่าเรากำลังทำอะไรบางอย่างอยู่ ดูเหมือนว่าเรากำลังจะผสานกันอยู่แล้ว แต่เราจะเข้าใจได้อย่างไรว่าเรายังมีการบูรณาการอย่างต่อเนื่อง ว่าเรารวมตัวกันค่อนข้างบ่อย?
Jez Humble เป็นผู้เขียนหนังสือ Handbook, Accelerate, เว็บไซต์ Continue Delivery และหนังสือเรื่อง Continue Delivery เขาเสนอการทดสอบนี้:
- รหัสของวิศวกรจะไปถึงอาจารย์ทุกวัน
- สำหรับทุก ๆ Commit คุณจะทำการทดสอบหน่วย
- งานสร้างในต้นแบบล้มลง แก้ไขได้ภายในเวลาประมาณ 10 นาที
เขาแนะนำให้ใช้แบบทดสอบเช่นนี้เพื่อให้แน่ใจว่าคุณฝึกฝนเพียงพอ
ฉันพบว่าสิ่งหลังมีความขัดแย้งเล็กน้อย นั่นคือหากคุณสามารถแก้ไขได้ภายใน 10 นาที แสดงว่าคุณมีการบูรณาการอย่างต่อเนื่อง ฟังดูแปลกนิดหน่อยในความคิดของฉัน แต่ก็สมเหตุสมผล ทำไม เพราะถ้าคุณหยุดบ่อย แสดงว่าการเปลี่ยนแปลงของคุณมีน้อย หากการเปลี่ยนแปลงเล็กน้อยหมายความว่างานสร้างต้นแบบของคุณเสียหาย คุณสามารถค้นหาตัวอย่างได้อย่างรวดเร็วเนื่องจากการเปลี่ยนแปลงมีขนาดเล็ก ที่นี่คุณมีการผสานเล็กน้อย โดยมีการเปลี่ยนแปลง 20-30 บรรทัด และด้วยเหตุนี้ คุณจึงสามารถเข้าใจได้อย่างรวดเร็วว่าสาเหตุคืออะไร เนื่องจากการเปลี่ยนแปลงมีขนาดเล็ก คุณจึงมีพื้นที่น้อยมากในการค้นหาปัญหา
และแม้ว่าผลิตภัณฑ์ของเราจะพังทลายลงหลังจากการเปิดตัว แต่หากเรามีแนวทางปฏิบัติในการบูรณาการอย่างต่อเนื่อง มันก็จะง่ายกว่ามากสำหรับเราที่จะดำเนินการ เนื่องจากการเปลี่ยนแปลงมีขนาดเล็กมาก ใช่ สิ่งนี้จะส่งผลต่อการวางแผน นี่จะเจ็บ และอาจเป็นสิ่งที่ยากที่สุดในการฝึกปฏิบัตินี้คือการทำความคุ้นเคยกับการแบ่งงานนั่นคือทำอย่างไรเพื่อให้คุณสามารถทำบางสิ่งบางอย่างและทำมันได้ภายในไม่กี่ชั่วโมงและในขณะเดียวกันก็ผ่านการทบทวนหาก คุณมีอันหนึ่ง การทบทวนเป็นความเจ็บปวดที่แยกจากกัน
การทดสอบหน่วยเป็นเพียงผู้ช่วยที่ช่วยให้คุณเข้าใจว่าการบูรณาการของคุณประสบความสำเร็จหรือไม่และไม่มีอะไรเสียหายหรือไม่ ในความคิดของฉัน สิ่งนี้ไม่ได้บังคับทั้งหมดเช่นกัน เพราะนี่ไม่ใช่ประเด็นของการปฏิบัติ
นี่เป็นการแนะนำโดยย่อเกี่ยวกับการบูรณาการอย่างต่อเนื่อง นั่นคือทั้งหมดที่มีสำหรับการปฏิบัตินี้ ฉันพร้อมสำหรับคำถาม
ฉันจะสรุปสั้น ๆ อีกครั้ง:
- การบูรณาการอย่างต่อเนื่องไม่ใช่เจนกินส์ ไม่ใช่ Gitlab
- นี่ไม่ใช่เครื่องมือ แต่เป็นวิธีปฏิบัติที่เรารวมโค้ดของเราเข้ากับต้นแบบบ่อยที่สุดเท่าที่จะทำได้
- เราทำสิ่งนี้เพื่อหลีกเลี่ยงความเจ็บปวดอันใหญ่หลวงที่เกิดขึ้นจากการผสานกันในอนาคต กล่าวคือ เราประสบกับความเจ็บปวดเล็กน้อยในขณะนี้ เพื่อจะได้ไม่ประสบอีกต่อไปในอนาคต นั่นคือประเด็นทั้งหมด
- ด้านข้างมีการสื่อสารผ่านโค้ด แต่ฉันไม่ค่อยเห็นสิ่งนี้มากนัก แต่นี่ก็เป็นสิ่งที่ออกแบบมาเพื่อเช่นกัน
คำถาม
จะทำอย่างไรกับงานที่ไม่สลายตัว?
ย่อยสลาย อะไรคือปัญหา? คุณช่วยยกตัวอย่างได้ไหมว่ามีงานแต่มันไม่สลายตัว?
มีงานที่ไม่สามารถแยกย่อยออกจากคำว่า “สมบูรณ์” ได้ เช่น งานที่ต้องอาศัยความเชี่ยวชาญเชิงลึกมากและสามารถแก้ไขได้จริงภายในเวลาหนึ่งเดือนเพื่อให้ได้ผลลัพธ์ที่ย่อยได้
ถ้าฉันเข้าใจคุณถูกต้องแสดงว่ามีงานใหญ่และซับซ้อนซึ่งผลลัพธ์จะมองเห็นได้ภายในหนึ่งเดือนเท่านั้น?
ถูกต้องเลย. ใช่ คุณสามารถประเมินผลลัพธ์ได้ไม่ช้ากว่าหนึ่งเดือน
ดี. โดยทั่วไปนี่ไม่ใช่ปัญหา ทำไม เพราะในกรณีนี้ เวลาเราพูดถึงกิ่ง เราไม่ได้หมายถึงกิ่งที่มีลักษณะเฉพาะ คุณลักษณะอาจมีขนาดใหญ่และซับซ้อน อาจส่งผลต่อส่วนประกอบจำนวนมาก และบางทีเราไม่สามารถทำทั้งหมดได้ในสาขาเดียว นี่เป็นเรื่องปกติ เราเพียงแค่ต้องทำลายเรื่องราวนี้ลง หากคุณสมบัติยังไม่พร้อมอย่างสมบูรณ์ ไม่ได้หมายความว่าโค้ดบางส่วนจะไม่สามารถรวมเข้าด้วยกันได้ คุณได้เพิ่ม เช่น การย้ายข้อมูล และมีบางขั้นตอนภายในคุณลักษณะนี้ สมมติว่าคุณมีขั้นตอน - ทำการโยกย้าย เพิ่มวิธีการใหม่ และคุณสามารถวัดสิ่งเหล่านี้ได้ทุกวัน
ดี. แล้วประเด็นคืออะไร?
การฆ่าสิ่งเล็กๆ น้อยๆ ทุกวันจะมีประโยชน์อะไร?
ใช่
หากพวกเขาทำสิ่งใดเสียหาย คุณจะเห็นมันทันที คุณมีชิ้นส่วนเล็กๆ ที่หักบางสิ่งบางอย่าง คุณจะแก้ไขได้ง่ายกว่า ประเด็นก็คือว่าตอนนี้การรวมชิ้นส่วนเล็กๆ เข้าด้วยกันนั้นง่ายกว่าการรวมชิ้นใหญ่ๆ ในเวลาไม่กี่สัปดาห์ และประเด็นที่สามก็คือวิศวกรคนอื่นๆ จะทำงานกับโค้ดเวอร์ชันปัจจุบันได้ พวกเขาจะเห็นว่ามีการเพิ่มการโยกย้ายบางส่วนที่นี่ และจากนั้นก็มีวิธีการบางอย่างปรากฏขึ้นว่าพวกเขาอาจต้องการใช้ด้วย ทุกคนจะเห็นสิ่งที่เกิดขึ้นในโค้ดของคุณ การฝึกปฏิบัติก็เพราะ ๓ ประการนี้.
ขอบคุณครับ ปิดประเด็นแล้ว!
(Oleg Soroka) ฉันขอเพิ่มได้ไหม? คุณพูดถูกทุกประการ ฉันแค่อยากจะเพิ่มวลีหนึ่ง
ดังนั้น
ด้วยการบูรณาการอย่างต่อเนื่อง โค้ดจะถูกรวมเข้ากับสาขาทั่วไป ไม่ใช่เมื่อคุณสมบัติพร้อมโดยสมบูรณ์ แต่เมื่อบิวด์หยุดทำงาน และคุณสามารถมุ่งมั่นที่จะเชี่ยวชาญได้อย่างปลอดภัยหลายครั้งต่อวันตามที่คุณต้องการ ด้านที่สองคือ ถ้าด้วยเหตุผลบางอย่างคุณไม่สามารถแบ่งงานรายเดือนเป็นงานเป็นเวลาอย่างน้อยสามวันได้ ฉันจะเงียบไปประมาณสามชั่วโมง แสดงว่าคุณมีปัญหาใหญ่ และการที่คุณไม่มีการบูรณาการอย่างต่อเนื่องก็เป็นปัญหาน้อยที่สุด ซึ่งหมายความว่าคุณมีปัญหากับสถาปัตยกรรมและแนวปฏิบัติด้านวิศวกรรมเป็นศูนย์ เพราะถึงแม้จะเป็นการวิจัย แต่อย่างไรก็ตาม ก็ต้องจัดทำขึ้นในรูปแบบของสมมติฐานหรือวัฏจักร
เราได้พูดคุยเกี่ยวกับตัวชี้วัด 4 ประการที่แยกแยะบริษัทที่ประสบความสำเร็จจากบริษัทที่ล้าหลัง เรายังต้องมีชีวิตอยู่เพื่อดูตัวชี้วัดทั้ง 4 นี้ หากงานโดยเฉลี่ยของคุณใช้เวลาหนึ่งเดือนจึงจะเสร็จสิ้น ฉันจะเน้นที่การวัดผลนี้ก่อน ผมจะลดให้เหลือ 3 วันก่อนนะครับ และหลังจากนั้นฉันก็เริ่มคิดถึงเรื่องต่อเนื่อง
ฉันเข้าใจคุณถูกต้องหรือไม่ที่คุณคิดว่าโดยทั่วไปแล้วไม่มีประโยชน์ที่จะลงทุนในการปฏิบัติงานด้านวิศวกรรมหากงานใดใช้เวลาหนึ่งเดือนจึงจะเสร็จสิ้น?
คุณมีการบูรณาการอย่างต่อเนื่อง และมีหัวข้อดังกล่าวว่าภายใน 10 นาทีคุณสามารถแก้ไขหรือย้อนกลับได้ ลองนึกภาพคุณกลิ้งมันออกมา ยิ่งไปกว่านั้น คุณยังมีการปรับใช้อย่างต่อเนื่อง คุณเผยแพร่สู่ผลิตภัณฑ์จริง และเพียงแต่สังเกตเห็นว่ามีบางอย่างผิดพลาด และคุณต้องย้อนกลับ แต่คุณได้ย้ายฐานข้อมูลของคุณแล้ว คุณมีสคีมาฐานข้อมูลของเวอร์ชันถัดไปอยู่แล้ว ยิ่งกว่านั้น คุณมีการสำรองข้อมูลบางประเภทด้วย และข้อมูลก็ถูกเขียนไว้ที่นั่นด้วย
และคุณมีทางเลือกอะไรอีกบ้าง? หากคุณย้อนกลับโค้ด จะไม่สามารถทำงานกับฐานข้อมูลที่อัปเดตนี้ได้อีกต่อไป
ฐานก้าวไปข้างหน้าเท่านั้นใช่
ผู้ที่มีการปฏิบัติงานด้านวิศวกรรมที่ไม่ดีมักไม่ได้อ่านหนังสือหนาเกี่ยวกับ... เช่นกัน จะทำอย่างไรกับการสำรองข้อมูล? หากคุณกู้คืนจากข้อมูลสำรอง หมายความว่าคุณสูญเสียข้อมูลที่สะสมไว้ในช่วงเวลานั้น ตัวอย่างเช่น เราทำงานเป็นเวลาสามชั่วโมงกับฐานข้อมูลเวอร์ชันใหม่ ซึ่งมีผู้ใช้ลงทะเบียนอยู่ที่นั่น คุณปฏิเสธการสำรองข้อมูลเก่าเนื่องจากรูปแบบนี้ใช้ไม่ได้กับเวอร์ชันใหม่ ดังนั้นคุณจึงสูญเสียผู้ใช้เหล่านี้ไป และพวกเขาไม่พอใจ พวกเขาสาบาน
เพื่อที่จะเชี่ยวชาญแนวทางปฏิบัติเต็มรูปแบบที่สนับสนุนการบูรณาการอย่างต่อเนื่องและการจัดส่งอย่างต่อเนื่อง การเรียนรู้วิธีการเขียนเพียงอย่างเดียวนั้นไม่เพียงพอ... ประการแรกอาจมีได้มากมาย แต่ก็ทำไม่ได้ นอกจากนี้ยังมีแนวทางปฏิบัติอื่นๆ อีกมากมาย เช่น Scientific มีแนวทางปฏิบัติเช่นนี้ GitHub ก็เผยแพร่ให้แพร่หลายในคราวเดียว นี่คือเมื่อคุณมีทั้งโค้ดเก่าและโค้ดใหม่ทำงานพร้อมกัน นี่คือเมื่อคุณสร้างฟีเจอร์ที่ยังสร้างไม่เสร็จ แต่สามารถส่งคืนค่าบางอย่างได้ ไม่ว่าจะเป็นฟังก์ชันหรือ Rest API คุณรันทั้งโค้ดใหม่และโค้ดเก่า และเปรียบเทียบความแตกต่างระหว่างโค้ดเหล่านั้น และหากมีความแตกต่าง คุณก็จะบันทึกเหตุการณ์นี้ วิธีนี้จะทำให้คุณรู้ว่าคุณมีฟีเจอร์ใหม่พร้อมที่จะเปิดตัวทับฟีเจอร์เก่า หากคุณไม่มีความแตกต่างระหว่างทั้งสองในช่วงเวลาหนึ่ง
มีแนวทางปฏิบัติดังกล่าวอยู่หลายร้อยวิธี ฉันขอแนะนำให้เริ่มต้นด้วยการพัฒนาทรานส์เบส เธอไม่ได้บูรณาการอย่างต่อเนื่อง 100% แต่แนวทางปฏิบัติก็เหมือนกัน ไม่มีใครสามารถอยู่ได้ดีหากไม่มีอีกคนหนึ่ง
คุณได้ยกตัวอย่างการพัฒนา Transbase ที่คุณสามารถเห็นแนวทางปฏิบัติหรือคุณแนะนำให้ผู้คนเริ่มใช้ debelopment ของ transbase หรือไม่?
ลองดูสิเพราะพวกเขาไม่สามารถใช้งานได้ เพื่อที่จะใช้งานคุณต้องอ่านให้มาก และเมื่อมีคนถามว่า “จะทำอย่างไรกับฟีเจอร์ที่ใช้เวลาเป็นเดือน แสดงว่าเขาไม่ได้อ่านเกี่ยวกับการพัฒนาทรานส์เบสเลย” ฉันคงไม่แนะนำมันในตอนนี้ ฉันขอแนะนำให้เน้นไปที่หัวข้อวิธีแบ่งงานใหญ่ให้เล็กลงตามหลักสถาปัตยกรรมอย่างถูกต้อง นี่คือสาระสำคัญของการสลายตัว
การสลายตัวเป็นหนึ่งในเครื่องมือของสถาปนิก ขั้นแรกเราทำการวิเคราะห์ จากนั้นจึงสลายตัว จากนั้นจึงสังเคราะห์ จากนั้นจึงรวมเข้าด้วยกัน และนี่คือวิธีที่ทุกอย่างได้ผลสำหรับเรา และเรายังต้องเติบโตไปสู่การบูรณาการอย่างต่อเนื่องผ่านการย่อยสลาย คำถามเกิดขึ้นในขั้นตอนแรก และเรากำลังพูดถึงขั้นตอนที่สี่อยู่แล้ว กล่าวคือ ยิ่งเราบูรณาการบ่อยเท่าไรก็ยิ่งดีเท่านั้น ยังเร็วเกินไปที่จะทำสิ่งนี้ เป็นการดีที่จะตัดเสาหินของคุณออกก่อน
คุณต้องวาดลูกศรและสี่เหลี่ยมจำนวนหนึ่งบนไดอะแกรมบางอัน คุณไม่สามารถพูดได้ว่าตอนนี้ฉันจะแสดงไดอะแกรมสถาปัตยกรรมของแอปพลิเคชันใหม่และแสดงหนึ่งช่องสี่เหลี่ยม ซึ่งภายในนั้นมีปุ่มสีเขียวสำหรับแอปพลิเคชัน ไม่ว่าในกรณีใดจะมีช่องสี่เหลี่ยมและลูกศรเพิ่มขึ้น ทุกแผนภาพที่ฉันเห็นมีมากกว่าหนึ่งแผนภาพ และการสลายตัวแม้กระทั่งในระดับการแสดงกราฟิกก็กำลังเกิดขึ้นแล้ว ดังนั้นสี่เหลี่ยมจัตุรัสจึงสามารถแยกเป็นอิสระได้ ถ้าไม่เช่นนั้น ฉันก็มีคำถามสำคัญสำหรับสถาปนิก
มีคำถามจากการแชทว่า “หากจำเป็นต้องตรวจสอบและใช้เวลานาน อาจจะเป็นวันหรือมากกว่านั้น?”
คุณมีปัญหากับการฝึกฝน การตรวจสอบไม่ควรใช้เวลาหนึ่งวันหรือมากกว่านั้น นี่เป็นเรื่องเดียวกันกับคำถามก่อนหน้า แต่นุ่มนวลกว่าเล็กน้อยเท่านั้น หากการรีวิวดำเนินไปเป็นเวลาหนึ่งวัน การรีวิวนี้น่าจะเกิดการเปลี่ยนแปลงครั้งใหญ่มาก ซึ่งหมายความว่าจะต้องทำให้เล็กลง ในการพัฒนา transbase ซึ่ง Oleg แนะนำมีเรื่องราวที่เรียกว่าการทบทวนอย่างต่อเนื่อง แนวคิดของเธอคือเราสร้างคำขอดึงข้อมูลเล็กๆ น้อยๆ โดยตั้งใจ เพราะเรามุ่งมั่นที่จะผสานรวมอย่างต่อเนื่องและทีละน้อย ดังนั้นคำขอดึงจึงเปลี่ยนหนึ่งนามธรรมหรือ 10 บรรทัด ขอบคุณรีวิวนี้ เราใช้เวลาสองสามนาที
หากการตรวจสอบใช้เวลาหนึ่งวันหรือมากกว่านั้น แสดงว่ามีสิ่งผิดปกติเกิดขึ้น ประการแรก คุณอาจมีปัญหากับสถาปัตยกรรม หรือนี่คือโค้ดชิ้นใหญ่ 1 บรรทัด เป็นต้น หรือสถาปัตยกรรมของคุณซับซ้อนมากจนบุคคลไม่สามารถเข้าใจได้ นี่เป็นปัญหาด้านข้างเล็กน้อย แต่ก็จะต้องแก้ไขด้วย บางทีก็ไม่จำเป็นต้องทบทวนอะไรเลย เราต้องคิดถึงเรื่องนี้ด้วย การทบทวนคือสิ่งที่ทำให้คุณช้าลง โดยทั่วไปมีข้อดีอยู่ แต่คุณต้องเข้าใจว่าเหตุใดคุณจึงทำเช่นนี้ นี่เป็นวิธีให้คุณถ่ายทอดข้อมูลได้อย่างรวดเร็ว นี่เป็นวิธีให้คุณกำหนดมาตรฐานภายในหรืออะไร? ทำไมคุณถึงต้องการสิ่งนี้? เพราะการตรวจสอบจะต้องดำเนินการอย่างรวดเร็วหรือยกเลิกไปเลย มันเหมือนกับการพัฒนาทรานส์เบส - เรื่องราวสวยงามมาก แต่สำหรับผู้ชายที่เป็นผู้ใหญ่เท่านั้น
สำหรับเมตริกทั้ง 4 รายการ ฉันยังคงแนะนำให้ลบเมตริกเหล่านั้นออกเพื่อทำความเข้าใจว่าสิ่งนี้นำไปสู่อะไร ดูตัวเลขดูรูปว่าแย่ทุกอย่าง
(Dmitry) ฉันพร้อมที่จะเข้าร่วมการสนทนาเกี่ยวกับเรื่องนี้กับคุณ ตัวเลขและหน่วยเมตริกล้วนยอดเยี่ยม ส่วนแนวทางปฏิบัติก็ยอดเยี่ยม แต่คุณต้องเข้าใจว่าธุรกิจต้องการมันหรือไม่ มีธุรกิจต่างๆ ที่ไม่ต้องการการเปลี่ยนแปลงที่รวดเร็วขนาดนั้น ฉันรู้ว่าบริษัทที่ไม่สามารถทำการเปลี่ยนแปลงทุกๆ 15 นาทีได้ และไม่ใช่เพราะพวกเขาแย่มาก นี่เป็นวงจรชีวิตเช่นนี้ และเพื่อให้ฟีเจอร์สาขา หรือฟีเจอร์สลับ คุณต้องมีความรู้เชิงลึก
มันซับซ้อน. หากคุณต้องการอ่านเรื่องราวเกี่ยวกับฟีเจอร์สลับโดยละเอียด ฉันขอแนะนำอย่างยิ่ง . และมีบทความที่ยอดเยี่ยมโดย Martin Fowler เกี่ยวกับคุณลักษณะการสลับ: มีประเภทใดบ้าง วงจรชีวิต ฯลฯ คุณลักษณะการสลับมีความซับซ้อน
และคุณยังไม่ได้ตอบคำถาม: “เจนกินส์จำเป็นหรือไม่?”
เจนกินส์ไม่จำเป็นเลยจริงๆ อย่างจริงจัง เครื่องมือ: Jenkins, Gitlab จะทำให้คุณสะดวกสบาย จะเห็นว่าการประกอบเป็นแบบประกอบหรือไม่ประกอบ พวกเขาสามารถช่วยคุณได้ แต่จะไม่ให้คุณฝึกฝน พวกเขาสามารถให้วงกลมแก่คุณเท่านั้น - โอเค ไม่ใช่ โอเค แล้วถ้าคุณเขียนแบบทดสอบด้วยเพราะหากไม่มีแบบทดสอบก็แทบจะไม่มีประโยชน์เลย เลยจำเป็นเพราะสะดวกกว่าแต่โดยทั่วไปอยู่ได้ถ้าไม่มีก็ไม่เสียอะไรมาก
นั่นคือถ้าคุณมีแนวทางปฏิบัตินั่นหมายความว่าคุณไม่ต้องการมันใช่ไหม?
ถูกตัอง. ฉันขอแนะนำการทดสอบ Jez Humble ที่นั่นฉันมีทัศนคติที่ไม่ชัดเจนต่อประเด็นสุดท้าย แต่โดยทั่วไป หากคุณมีสามสิ่ง คุณผสานอย่างต่อเนื่อง คุณรันการทดสอบการคอมมิตในต้นแบบ คุณแก้ไขบิลด์ในต้นแบบอย่างรวดเร็ว จากนั้นบางทีคุณอาจไม่ต้องการสิ่งอื่นใดอีก
ระหว่างรอคำถามจากผู้เข้าร่วม ฉันก็มีคำถาม เราแค่พูดถึงรหัสผลิตภัณฑ์ คุณเคยใช้มันเป็นรหัสโครงสร้างพื้นฐานหรือไม่? เป็นรหัสเดียวกัน มีหลักการและวงจรชีวิตเดียวกัน หรือมีวงจรชีวิตและหลักการต่างกันหรือไม่ โดยปกติแล้ว เมื่อทุกคนพูดถึงการบูรณาการและการพัฒนาอย่างต่อเนื่อง ทุกคนจะลืมไปว่ายังมีโค้ดโครงสร้างพื้นฐานอยู่ด้วย และช่วงนี้ก็มีมากขึ้นเรื่อยๆ และควรนำกฎทั้งหมดนี้ไปที่นั่นหรือไม่?
แม้ไม่ควรจะเป็นก็ยังดีเพราะจะทำให้ชีวิตง่ายขึ้นไปในทางเดียวกัน ทันทีที่เราทำงานกับโค้ด ไม่ใช่กับสคริปต์ทุบตี แต่เรามีโค้ดปกติ
หยุด หยุด สคริปต์ทุบตีก็เป็นโค้ดเช่นกัน อย่าแตะต้องรักเก่าของฉัน
โอเค ฉันจะไม่เหยียบย่ำความทรงจำของคุณ ฉันไม่ชอบทุบตีเป็นการส่วนตัว มันแตกน่าเกลียดและน่ากลัวตลอดเวลา และมันมักจะพังอย่างคาดเดาไม่ได้ ซึ่งเป็นเหตุผลว่าทำไมฉันถึงไม่ชอบมัน แต่เอาล่ะ สมมติว่าคุณมีโค้ดทุบตี บางทีฉันอาจไม่เข้าใจจริงๆ และมีกรอบการทดสอบปกติอยู่ที่นั่น ฉันแค่ไม่อยู่ในความรู้ และเราก็ได้รับผลประโยชน์เช่นเดียวกัน
ทันทีที่เราทำงานกับโครงสร้างพื้นฐานเป็นโค้ด เราก็จะประสบปัญหาเดียวกันกับนักพัฒนา เมื่อไม่กี่เดือนที่ผ่านมา ฉันพบกับสถานการณ์ที่เพื่อนร่วมงานส่งคำขอดึงข้อมูลจำนวน 1 บรรทัดมาให้ฉัน และคุณนั่งรีวิวเป็นเวลา 000 ชั่วโมง ปัญหาเดียวกันก็เกิดขึ้น ยังคงเป็นรหัสอยู่ครับ และยังคงเป็นความร่วมมือ เราติดอยู่กับคำขอการดึงและเราติดอยู่กับความจริงที่ว่าเรากำลังแก้ไขข้อขัดแย้งในการผสานเดียวกันใน bash เดียวกัน
ตอนนี้ฉันกำลังดูสิ่งทั้งหมดนี้เกี่ยวกับโปรแกรมอินฟาเรดที่สวยงามที่สุด ตอนนี้ฉันได้นำ Pulumi เข้าสู่โครงสร้างพื้นฐานแล้ว นี่คือการเขียนโปรแกรมในรูปแบบที่บริสุทธิ์ที่สุด ที่นั่นจะดีกว่านี้อีกเพราะฉันมีความสามารถทั้งหมดของภาษาการเขียนโปรแกรม เช่น ฉันสร้างการสลับที่สวยงามโดยไม่ได้ตั้งใจด้วย ifs เดียวกัน และทุกอย่างเรียบร้อยดี นั่นคือการเปลี่ยนแปลงของฉันอยู่ในต้นแบบแล้ว ทุกคนสามารถเห็นเขาได้แล้ว วิศวกรคนอื่นรู้เรื่องนี้ มันมีอิทธิพลต่อบางสิ่งบางอย่างที่นั่นแล้ว อย่างไรก็ตาม ไม่ได้เปิดใช้งานสำหรับโครงสร้างพื้นฐานทั้งหมด ตัวอย่างเช่น มันเปิดอยู่บนม้านั่งทดสอบของฉัน จึงต้องตอบคำถามของคุณอีกครั้ง มันทำให้ชีวิตง่ายขึ้นสำหรับเราในฐานะวิศวกรที่ทำงานกับโค้ดในลักษณะเดียวกัน
หากใครมีคำถามอีก?
ฉันมีคำถาม. ฉันต้องการพูดคุยกับ Oleg ต่อไป โดยทั่วไปผมคิดว่าคุณพูดถูกว่าถ้างานใช้เวลาหนึ่งเดือนจึงจะเสร็จ คุณจะมีปัญหากับสถาปัตยกรรม คุณมีปัญหากับการวิเคราะห์ การสลายตัว การวางแผน ฯลฯ แต่ฉันมีความรู้สึกว่าถ้าคุณเริ่ม พยายามดำเนินชีวิตตาม Continent Integration แล้วคุณจะเริ่มแก้ไขความเจ็บปวดด้วยการวางแผนเพราะคุณจะไม่หนีจากที่อื่น
(Oleg) ใช่แล้ว ถูกต้องแล้ว การปฏิบัตินี้เทียบได้กับความพยายามกับการปฏิบัติที่เปลี่ยนแปลงวัฒนธรรมอย่างจริงจังอื่นๆ สิ่งที่ยากที่สุดที่จะเอาชนะได้คือนิสัย โดยเฉพาะนิสัยที่ไม่ดี และหากเพื่อที่จะนำแนวปฏิบัตินี้ไปใช้ จำเป็นต้องมีการเปลี่ยนแปลงพฤติกรรมของคนรอบข้างอย่างจริงจัง เช่น นักพัฒนา ฝ่ายบริหาร ผู้จัดการฝ่ายผลิต และความประหลาดใจรอคุณอยู่
จะมีเซอร์ไพรส์อะไรบ้าง? สมมติว่าคุณตัดสินใจว่าจะบูรณาการบ่อยขึ้น และคุณมีสิ่งอื่นๆ บางอย่างที่เชื่อมโยงกับการบูรณาการ เช่น อาร์ติแฟกต์ ตัวอย่างเช่น ในบริษัทของคุณ มีนโยบายว่าสิ่งประดิษฐ์ทุกชิ้นจะต้องถูกนำมาพิจารณาในระบบการจัดเก็บสิ่งประดิษฐ์บางประเภทในทางใดทางหนึ่ง และต้องใช้เวลาพอสมควร บุคคลต้องทำเครื่องหมายในช่องว่าเขาในฐานะผู้จัดการรุ่นได้ทดสอบอาร์ติแฟกต์นี้เพื่อให้แน่ใจว่าพร้อมสำหรับการเปิดตัวในการใช้งานจริง หากใช้เวลา 5-10-15 นาที แต่คุณทำเค้าโครงสัปดาห์ละครั้ง การใช้เวลาครึ่งชั่วโมงสัปดาห์ละครั้งถือเป็นภาษีเล็กน้อย
หากคุณทำการบูรณาการอย่างต่อเนื่อง 10 ครั้งต่อวัน จะต้องคูณ 10 ครั้งด้วย 30 นาที และนี่เกินระยะเวลาการทำงานของผู้จัดการรุ่นนี้ เขาแค่เบื่อที่จะทำมัน มีค่าใช้จ่ายคงที่สำหรับการปฏิบัติบางอย่าง นั่นคือทั้งหมดที่
และคุณต้องยกเลิกกฎนี้เพื่อที่คุณจะได้ไม่ทำขยะอีกต่อไปเช่น คุณไม่ได้กำหนดระดับให้สอดคล้องกับบางสิ่งบางอย่างด้วยตนเอง คุณกำลังพึ่งพาชุดการทดสอบความพร้อมอัตโนมัติบางชุดโดยสิ้นเชิง
และหากคุณต้องการหลักฐานจากใครสักคนเพื่อให้เจ้านายเซ็นชื่อและคุณไม่สามารถเข้าสู่การผลิตโดยที่ Vasya บอกว่าเขาอนุญาต ฯลฯ - เรื่องไร้สาระทั้งหมดนี้เข้ามาขวางทางผู้ประกอบวิชาชีพ เพราะหากมีกิจกรรมบางอย่างที่เกี่ยวข้องกับภาษี ทุกอย่างจะเพิ่มขึ้น 100 เท่า ดังนั้นการเปลี่ยนแปลงมักจะไม่ได้รับการต้อนรับด้วยความยินดีจากทุกคน เพราะนิสัยคนเราเปลี่ยนแปลงยาก
เมื่อคนๆ หนึ่งทำงานตามปกติของเขา เขาแทบจะทำโดยไม่คิดอะไรเลย ภาระการรับรู้ของเธอเป็นศูนย์ เขาแค่เล่นกับมัน เขามีรายการตรวจสอบในหัวอยู่แล้ว เขาทำมันมาแล้วนับพันครั้ง และทันทีที่คุณมาบอกเขาว่า “เรามายกเลิกแบบฝึกหัดนี้แล้วแนะนำวิธีใหม่ตั้งแต่วันจันทร์กันเถอะ” สำหรับเขาแล้ว มันจะกลายเป็นภาระทางการรับรู้อันทรงพลังสำหรับเขา และมันมาถึงทุกคนทันที
ดังนั้นสิ่งที่ง่ายที่สุดแม้ว่าจะไม่ใช่ทุกคนที่จะสามารถซื้อความหรูหรานี้ได้ แต่นี่คือสิ่งที่ฉันทำอยู่เสมอนี่คือสิ่งต่อไปนี้ หากโปรเจ็กต์ใหม่เริ่มต้นขึ้น โดยปกติแล้วแนวทางปฏิบัติที่ยังไม่ผ่านการทดสอบทั้งหมดจะอัดแน่นอยู่ในโปรเจ็กต์นี้ทันที แม้ว่าโปรเจ็กต์นี้ยังใหม่อยู่ เราก็ไม่ได้เสี่ยงอะไรเลย ยังไม่มีผลิตภัณฑ์ ไม่มีอะไรจะทำลาย ดังนั้นจึงสามารถใช้เป็นแบบฝึกหัดได้ แนวทางนี้ใช้ได้ผล แต่ไม่ใช่ทุกบริษัทที่จะมีโอกาสเริ่มโครงการดังกล่าวบ่อยครั้ง แม้จะแปลกไปสักหน่อย แต่เนื่องจากขณะนี้มีการเปลี่ยนแปลงทางดิจิทัลอย่างสมบูรณ์ ทุกคนจึงต้องทำการทดลองเพื่อให้ตามทันคู่แข่ง
ที่นี่คุณมาถึงข้อสรุปว่าคุณต้องมีความเข้าใจในสิ่งที่คุณต้องทำก่อน โลกไม่เหมาะ และผลิตผลก็ไม่เหมาะเช่นกัน
ใช่แล้ว สิ่งเหล่านี้เชื่อมโยงถึงกัน
ธุรกิจก็ไม่เข้าใจเสมอไปว่าพวกเขาจำเป็นต้องทำเช่นนี้
มีสถานการณ์ที่ไม่สามารถเปลี่ยนแปลงได้เลย นี่คือสถานการณ์ที่มีความกดดันต่อทีมมากขึ้น ทีมค่อนข้างเหนื่อยหน่ายแล้ว เธอไม่มีเวลาว่างสำหรับการทดลองใดๆ พวกเขาทำงานกับฟีเจอร์ตั้งแต่เช้าถึงเย็น และฝ่ายบริหารก็มีคุณสมบัติน้อยลงเรื่อยๆ จำเป็นต้องมีมากขึ้นเรื่อยๆ ในสถานการณ์เช่นนี้ ไม่สามารถเปลี่ยนแปลงได้เลย ทีมงานบอกได้คำเดียวว่าพรุ่งนี้เราจะทำเหมือนเมื่อวานเราแค่ต้องเพิ่มฟีเจอร์อีกนิดหน่อย ในแง่นี้ จึงไม่สามารถเปลี่ยนแปลงไปสู่แนวทางปฏิบัติใดๆ ได้ นี่เป็นสถานการณ์คลาสสิกเมื่อไม่มีเวลาลับขวาน ต้นไม้จำเป็นต้องโค่นลง จึงใช้ขวานทื่อตัดมัน ไม่มีเคล็ดลับง่ายๆที่นี่
(Dmitry) ฉันจะอ่านคำชี้แจงจากการแชท: “แต่เราต้องการความครอบคลุมการทดสอบจำนวนมากในระดับต่างๆ จัดสรรเวลาเท่าไรในการทดสอบ? มันแพงนิดหน่อยและใช้เวลานาน”
(Oleg) นี่เป็นความเข้าใจผิดแบบคลาสสิก ควรมีการทดสอบเพียงพอเพื่อให้คุณมั่นใจ การบูรณาการอย่างต่อเนื่องไม่ใช่สิ่งที่จะทำแบบทดสอบ 100% ก่อน จากนั้นจึงเริ่มนำแนวทางปฏิบัตินี้ไปใช้เท่านั้น การบูรณาการอย่างต่อเนื่องจะช่วยลดภาระการรับรู้ของคุณ เนื่องจากการเปลี่ยนแปลงแต่ละครั้งที่คุณเห็นด้วยตานั้นชัดเจนมากจนคุณเข้าใจว่ามันจะทำลายบางสิ่งบางอย่างหรือไม่ แม้ว่าจะไม่มีการทดสอบก็ตาม คุณสามารถทดสอบสิ่งนี้ในหัวของคุณได้อย่างรวดเร็วเนื่องจากการเปลี่ยนแปลงมีขนาดเล็ก แม้ว่าคุณจะมีเพียงผู้ทดสอบด้วยตนเอง แต่ก็ง่ายกว่าสำหรับพวกเขาเช่นกัน คุณกลิ้งตัวออกไปแล้วพูดว่า:“ ดูสิมีอะไรพังหรือเปล่า?” พวกเขาตรวจสอบแล้วพูดว่า “ไม่มี ไม่มีอะไรเสียหาย” เพราะผู้ทดสอบรู้ว่าจะต้องดูที่ไหน คุณมีหนึ่งการกระทำที่เกี่ยวข้องกับโค้ดชิ้นเดียว และสิ่งนี้ถูกเอารัดเอาเปรียบโดยพฤติกรรมเฉพาะ
แน่นอนว่าคุณประดับประดาที่นี่
(Dmitry) ฉันไม่เห็นด้วยที่นี่ มีแนวทางปฏิบัติ - การพัฒนาแบบทดสอบซึ่งจะช่วยคุณจากสิ่งนี้
(Oleg) ฉันยังไปไม่ถึงจุดนั้น ภาพลวงตาแรกคือคุณต้องเขียนการทดสอบ 100% หรือคุณไม่จำเป็นต้องทำการบูรณาการอย่างต่อเนื่องเลย มันไม่เป็นความจริง นี่เป็นการปฏิบัติสองประการคู่ขนานกัน และไม่ได้ขึ้นอยู่กับโดยตรง ความครอบคลุมการทดสอบของคุณต้องเหมาะสมที่สุด เหมาะสมที่สุด - นี่หมายความว่าคุณเองมั่นใจว่าคุณภาพของปรมาจารย์ที่เจ้านายของคุณยังคงอยู่หลังจากการคอมมิตช่วยให้คุณกดปุ่ม "ปรับใช้" ได้อย่างมั่นใจในช่วงเย็นวันศุกร์ที่เมาสุรา คุณบรรลุเป้าหมายนี้ได้อย่างไร? ผ่านการทบทวน ผ่านการครอบคลุม ผ่านการกำกับดูแลที่ดี
การตรวจสอบที่ดีนั้นแยกไม่ออกจากการทดสอบ หากคุณทำการทดสอบหนึ่งครั้งในช่วงก่อนการผลิต พวกเขาจะตรวจสอบสคริปต์ผู้ใช้ทั้งหมดของคุณเพียงครั้งเดียวเท่านั้น และถ้าคุณรันมันแบบวนซ้ำไม่รู้จบ นี่คือระบบการตรวจสอบที่คุณใช้งาน ซึ่งจะทดสอบทุกอย่างอย่างไม่มีที่สิ้นสุด ไม่ว่าจะพังหรือไม่ก็ตาม ในกรณีนี้ ข้อแตกต่างเพียงอย่างเดียวคือทำครั้งเดียวหรือสองครั้ง ชุดการทดสอบที่ดีมาก... ดำเนินไปอย่างไม่มีที่สิ้นสุด นี่คือการตรวจสอบ และการเฝ้าระวังที่ถูกต้องควรเป็นเช่นนี้
ดังนั้นคุณจะบรรลุสภาวะนี้ได้อย่างไรเมื่อคุณเตรียมพร้อมในเย็นวันศุกร์และกลับบ้านเป็นอีกคำถามหนึ่ง บางทีคุณอาจเป็นเพียงคนหลอกลวงที่กล้าหาญ
ย้อนกลับไปที่การบูรณาการอย่างต่อเนื่องกันเล็กน้อย เราวิ่งหนีไปสู่แนวทางปฏิบัติที่ซับซ้อนแตกต่างออกไปเล็กน้อย
และภาพลวงตาประการที่สองก็คือ พวกเขากล่าวว่า MVP จำเป็นต้องทำให้เสร็จอย่างรวดเร็ว ดังนั้นจึงไม่จำเป็นต้องทำการทดสอบเลย ไม่เป็นอย่างนั้นอย่างแน่นอน ความจริงก็คือเมื่อคุณเขียนเรื่องราวของผู้ใช้ใน MVP คุณสามารถพัฒนามันบนลูกบอลได้นั่นคือคุณได้ยินมาว่ามีเรื่องราวของผู้ใช้บางประเภทและรีบวิ่งไปเขียนโค้ดทันทีหรือคุณจะทำงานโดยใช้ TDD ก็ได้ และตาม TDD ดังที่แสดงให้เห็นในทางปฏิบัติ การทดสอบใช้เวลาไม่นาน กล่าวคือ การทดสอบถือเป็นผลข้างเคียง การปฏิบัติของ TDD ไม่ได้เกี่ยวกับการทดสอบ แม้ว่าสิ่งที่เรียกว่า Test Driven Development แต่ก็ไม่เกี่ยวกับการทดสอบเลย นี่เป็นแนวทางทางสถาปัตยกรรมมากกว่า นี่เป็นแนวทางในการเขียนสิ่งที่จำเป็นอย่างแท้จริง ไม่ใช่เขียนสิ่งที่ไม่จำเป็น นี่คือแนวทางปฏิบัติในการมุ่งเน้นไปที่การทบทวนความคิดของคุณครั้งถัดไปในแง่ของการสร้างสถาปัตยกรรมแอปพลิเคชัน
ดังนั้นจึงไม่ง่ายเลยที่จะกำจัดภาพลวงตาเหล่านี้ MVP และการทดสอบไม่ขัดแย้งกัน ในทางกลับกัน หากคุณทำ MVP โดยใช้การฝึกซ้อม TDD คุณจะทำได้ดีกว่าและเร็วกว่าการที่คุณไม่ได้ฝึกซ้อมเลย แต่ทำได้บนลูกบอล
นี่เป็นแนวคิดที่ไม่ชัดเจนและซับซ้อนมาก เมื่อคุณได้ยินว่าตอนนี้ฉันจะเขียนแบบทดสอบเพิ่มเติม และในขณะเดียวกันฉันก็จะทำบางอย่างให้เร็วขึ้นด้วย ฟังดูยังไม่เพียงพอเลย
(Dmitry) หลายๆ คนที่นี่ เมื่อพวกเขาเรียกว่า MVP ผู้คนก็ขี้เกียจเกินกว่าจะเขียนอะไรที่ธรรมดาๆ และสิ่งเหล่านี้ก็ยังคงเป็นสิ่งที่แตกต่างออกไป ไม่จำเป็นต้องเปลี่ยน MVP ให้เป็นสิ่งเลวร้ายที่ไม่ได้ผล
ใช่ใช่คุณพูดถูก
และแล้วจู่ๆ ก็ได้ MVP ในผลิตภัณฑ์
ตลอดไป
และ TDD ฟังดูผิดปกติมากเมื่อคุณได้ยินว่าคุณเขียนการทดสอบและดูเหมือนว่าจะทำงานได้มากกว่านี้ ฟังดูแปลกมาก แต่จริงๆ แล้ววิธีนี้กลับกลายเป็นว่าเร็วขึ้นและสวยกว่า เมื่อคุณเขียนแบบทดสอบ คุณคิดมากมายในหัวแล้วว่าโค้ดใดจะถูกเรียกและอย่างไร รวมถึงพฤติกรรมที่เราคาดหวังจากโค้ดนั้นด้วย คุณไม่เพียงแค่บอกว่าฉันเขียนฟังก์ชันบางอย่างแล้วมันก็ทำอะไรบางอย่าง ตอนแรกเธอคิดว่าเธอมีเงื่อนไขเช่นนั้น เธอคงถูกเรียกร้องในลักษณะเช่นนี้ คุณครอบคลุมสิ่งนี้ด้วยการทดสอบ และจากนี้ คุณจะเข้าใจว่าอินเทอร์เฟซของคุณจะมีลักษณะอย่างไรในโค้ดของคุณ สิ่งนี้มีผลกระทบอย่างมากต่อสถาปัตยกรรม โค้ดของคุณจะกลายเป็นโมดูลาร์มากขึ้นโดยอัตโนมัติ เนื่องจากคุณต้องพยายามทำความเข้าใจก่อนว่าคุณจะทดสอบอย่างไร จากนั้นจึงเขียนโค้ดเท่านั้น
สิ่งที่เกิดขึ้นกับฉันกับ TDD คือเมื่อถึงจุดหนึ่งฉันได้จ้างที่ปรึกษา Ruby เมื่อตอนที่ฉันยังเป็นโปรแกรมเมอร์ Ruby และเขาพูดว่า: "มาทำตาม TDD กันเถอะ" ฉันคิดว่า: "ให้ตายเถอะ ตอนนี้ฉันต้องเขียนอะไรบางอย่างเพิ่มเติม" และเราตกลงกันว่าภายในสองสัปดาห์ ฉันจะเขียนโค้ดการทำงานทั้งหมดใน Python โดยใช้ TDD หลังจากผ่านไปสองสัปดาห์ ฉันก็ตระหนักว่าฉันไม่อยากกลับไป หลังจากพยายามใช้สิ่งนี้ทุกที่เป็นเวลาสองสัปดาห์ คุณจะรู้ว่ามันง่ายแค่ไหนสำหรับคุณที่จะคิด แต่สิ่งนี้ไม่ชัดเจน ดังนั้นฉันขอแนะนำให้ทุกคนทราบว่าหากคุณรู้สึกว่า TDD เป็นเรื่องยาก ใช้เวลานาน และไม่จำเป็น ให้ลองใช้มันต่อไปเป็นเวลาเพียงสองสัปดาห์ สองอันก็เพียงพอสำหรับฉัน
(Dmitry) เราสามารถขยายแนวคิดนี้จากมุมมองของการดำเนินงานโครงสร้างพื้นฐานได้ ก่อนที่เราจะเปิดตัวสิ่งใหม่ๆ เราจะติดตามและเปิดตัวก่อน ในกรณีนี้ การตรวจสอบจะกลายเป็นการทดสอบปกติสำหรับเรา และมีการพัฒนาผ่านการเฝ้าติดตาม แต่เกือบทุกคนบอกว่ามันยาว ขี้เกียจ ทำร่างชั่วคราว หากเราทำการตรวจสอบตามปกติ เราก็จะเข้าใจสถานะของระบบ CI และระบบ CI มีการตรวจสอบจำนวนมาก เราเข้าใจสถานะของระบบ เราเข้าใจสิ่งที่อยู่ภายในนั้น และในระหว่างการพัฒนา เราแค่สร้างระบบให้ถึงสถานะที่ต้องการ
แนวทางปฏิบัติเหล่านี้ทราบกันมานานแล้ว เราคุยกันเรื่องนี้เมื่อประมาณ 4 ปีที่แล้ว แต่ใน 4 ปีไม่มีอะไรเปลี่ยนแปลงเลย
แต่ในบันทึกนี้ ฉันขอเสนอให้ยุติการสนทนาอย่างเป็นทางการ
วิดีโอ (แทรกเป็นองค์ประกอบสื่อ แต่ด้วยเหตุผลบางอย่างใช้งานไม่ได้):
ที่มา: will.com