เมื่อใดควรอัปเดตการอ้างอิง

เรามีสองวิกฤตที่เกี่ยวข้องกับการพึ่งพาที่สำคัญสองฐานรหัสที่แตกต่างกัน (Android และเว็บแอป Node.js) repo Android จำเป็นต้องโยกย้ายจาก Flurry ไปยัง Firebase ซึ่งจำเป็นต้องอัปเดตห้องสมุด Google Play Services สี่เวอร์ชันหลัก มีสิ่งที่คล้ายกันเกิดขึ้นกับแอปโหนดที่โฮสต์โดย Heroku ซึ่งสแตกการผลิต (ซีดาร์) ของเราถูกเลิกใช้และจำเป็นต้องได้รับการอัพเกรดเป็นซีดาร์ -14 ฐานข้อมูล PostgreSQL ของเรายังต้องมีการอัพเดทจาก 9.2 เป็น 9.6

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

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

ควรอัปเดตการอ้างอิงบ่อยเพียงใดหรือควรอัปเดตการอ้างอิงเมื่อใด เราอัปเดตเพราะเราถูกบังคับ แต่ดูเหมือนว่าวิธีการจองล่วงหน้าบางประเภทจะดีกว่า เราควรอัปเดตเมื่อมีรุ่นย่อยออกมาหรือไม่ รุ่นใหญ่? ทุกเดือนหากมีการอัปเดต ฉันต้องการหลีกเลี่ยงสถานการณ์เช่นเดียวกับสิ่งที่ฉันเพิ่งประสบกับค่าใช้จ่ายทั้งหมด

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

โดยทั่วไปคุณควรอัพเกรดการพึ่งพาเมื่อ:

1. มันต้องการ
2. มีข้อดีที่จะทำเช่นนั้น
3. การไม่ทำเช่นนั้นเป็นข้อเสีย

(สิ่งเหล่านี้ไม่ได้เกิดร่วมกัน)

แรงจูงใจ 1 ("เมื่อคุณต้อง") เป็นตัวเร่งด่วนที่สุด ส่วนประกอบหรือแพลตฟอร์มบางอย่างที่คุณต้องพึ่งพา (เช่น Heroku) ต้องการมันและคุณต้องตกอยู่ในสาย การอัพเกรดที่ต้องการมักจะแยกออกจากตัวเลือกอื่น ๆ คุณตัดสินใจที่จะอัปเกรดเป็นรุ่น PostgreSQL เช่นนั้น ตอนนี้คุณต้องอัพเดตไดรเวอร์เวอร์ชั่น ORM ของคุณเป็นต้น

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

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

จากมุมมองที่ใช้งานได้จริงทีมของคุณต้องให้ความสำคัญกับปัญหาการดริฟท์ 2 ปีนานเกินไป ไม่มีเวทย์มนตร์ เป็นเพียงเรื่องของ "จ่ายเงินให้ฉันตอนนี้หรือจ่ายทีหลัง" ไม่ว่าจะเป็นปัญหาการดริฟท์รุ่นที่เพิ่มขึ้นหรือประสบและจากนั้นได้รับการกระแทกที่ใหญ่กว่าทุกสองสามปี ฉันชอบการเพิ่มขึ้นเนื่องจากแพลตฟอร์มบางอันมีขนาดใหญ่มาก API หรือแพลตฟอร์มหลักที่คุณพึ่งพาไม่ได้ทำงานอีกต่อไปสามารถทำลายวันสัปดาห์หรือเดือนของคุณได้ ฉันชอบที่จะประเมินความสดใหม่ขององค์ประกอบอย่างน้อย 1-2 ครั้งต่อปี คุณสามารถกำหนดเวลาการตรวจสอบอย่างชัดเจนหรือปล่อยให้มีการเรียกใช้แบบออร์แกนิกโดยใช้ metronomic ซึ่งโดยปกติจะเป็นวัฏจักรการอัพเดทประจำปีขององค์ประกอบหลักเช่น Python, PostgreSQL และ node.js หากการอัพเดทส่วนประกอบไม่ได้กระตุ้นให้ทีมของคุณแข็งแกร่งมากการตรวจสอบความสดใหม่ของการออกรุ่นใหญ่ ที่ plateaus โครงการธรรมชาติหรือทุก ๆ k รีลีสสามารถใช้ได้ สิ่งที่ให้ความสนใจกับการแก้ไขการดริฟท์เวอร์ชั่นในจังหวะปกติมากขึ้น

ควรอัพเดตไลบรารีเมื่อจำเป็นต้องได้รับการอัพเดต นั่นหมายความว่าหากการอัปเดตไม่มีคุณค่าคุณก็ไม่ควรทำ

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

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

อย่างไรก็ตามหากคุณพบว่ามันยากที่จะโยกย้ายและต้องทำ refactor จำนวนมากโอกาสที่จะเกิดปัญหานั้นอยู่ใน codebase ของคุณ เป็นเรื่องปกติสำหรับโครงการ Android ที่จะไม่มีสถาปัตยกรรมโดยรวมในแง่ของโครงสร้างรหัส กรอบการฉีดที่ดีเช่นDagger 2และหลักการทางวิศวกรรมซอฟต์แวร์สองอย่างเช่นSOLIDทำให้การเปลี่ยนการใช้โค้ดง่ายขึ้นในขณะที่ยังคงมีพฤติกรรม / ข้อกำหนดเดียวกัน

นอกจากนี้เนื่องจากเรากำลังทำการรีแฟคเตอร์ให้อ่านเล็กน้อยเกี่ยวกับการทดสอบหน่วยเนื่องจากจะช่วยได้มากเมื่อทำงานประเภทนี้

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

ตราบใดที่ค่าใช้จ่ายในการอัพเกรดการพึ่งพาอยู่ในระดับต่ำมันก็คุ้มค่าที่จะต้องอัพเดทอยู่เสมอ:

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

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

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

เช่นหากคุณใช้ V1 และยังคงรองรับคุณยังสามารถใช้รุ่นล่าสุดของ v1 ได้

ครั้งเดียวที่คุณควรล้าสมัยคือ:

ตอบ: คุณยังไม่ได้เผยแพร่ในบางครั้ง

B: คุณใช้ v1 มานานแล้วและไม่รองรับอีกต่อไป

มีการเปิดตัวการปรับปรุงด้วยเหตุผลว่ามีการแก้ไขความปลอดภัยที่คุณควรเข้าร่วม

หากเวอร์ชันใหม่ของการขึ้นต่อกันของคุณออกมาคุณควรทำรีลีสด้วย

ฉันคิดว่ามันต้องขึ้นอยู่กับห้องสมุดที่มีปัญหา แต่ฉันมีอาการปวดหัวคล้าย ๆ กัน

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

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

ไลบรารี่ควรได้รับการอัพเดตเมื่อมีข้อได้เปรียบที่ซอฟต์แวร์ของคุณจะใช้เพื่อชดเชยงานที่ใช้ในการเปลี่ยนแปลง

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

ไม่มีความละอายในการใช้ libs เก่า เมื่อจำเป็นต้องเปลี่ยนแปลงอาจจะเจ็บปวด แต่มันเป็นส่วนหนึ่งของงาน