พื้นหลัง

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

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

สิ่งที่ฉันกำลังมองหา

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

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

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

// TODO by v55: Create migration to move constraints to new column, remove references to old column in app
// TODO by v56: Create migration to drop old column

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

ความคิดเพิ่มเติม

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

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

คำถามนี้เป็นคำถามสองข้อในหนึ่งเดียว

ความคิดเห็นสิ่งที่ต้องทำ

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

จะทำอย่างไรกับมัน

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

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

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

การเปลี่ยนแปลงฐานข้อมูล

ใช่การเปลี่ยนแปลงฐานข้อมูลเป็นเรื่องยากด้วยนโยบายการหยุดทำงานศูนย์ เทคนิคบางอย่างที่จะช่วยทำให้เจ็บปวดน้อยลง:

กระบวนการหลังการปรับใช้

สร้างกระบวนการหลังการปรับใช้ที่ทำงานเป็นส่วนหนึ่งของรุ่นเดียวกัน อย่างไรก็ตามคุณต้องการให้มันทำงาน ในระบบสุดท้ายที่ฉันทำงานฉันออกแบบการปรับใช้แบบ 4 เฟส:

1. พรีสคริปต์ฐานข้อมูลล่วงหน้า
2. เว็บแอพ
3. สคริปต์ฐานข้อมูล postapp
4. สคริปต์ฐานข้อมูลการบำรุงรักษาหน้าต่าง

แนวคิดก็คือเมื่อใดก็ตามที่เป็นไปได้เราจะทำการเปลี่ยนแปลงฐานข้อมูลให้มากที่สุดเท่าที่จะเป็นไปได้

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

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

ปรับใช้บ่อยครั้ง

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

อย่าใช้สิ่งที่ต้องทำ คุณมีรายการสิ่งที่ต้องทำในโครงการของคุณแล้ว มันเรียกว่าตัวติดตามปัญหา

ฉันคิดว่าปัญหาที่แท้จริงคือประโยคนี้:

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

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

หากการจัดการของคุณล่าช้าส่วนสุดท้ายของงานที่ไม่เหมาะสมคุณมีสองตัวเลือก:

1. พูดคุยกับผู้บริหารของคุณว่าทำไมมันเป็นความคิดที่ไม่ดี

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

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

สิ่งที่คุณขอทำได้เมื่อคุณเต็มใจทำงานและติดตาม

// TODO โดย v55: สร้างการโยกย้ายเพื่อย้ายข้อ จำกัด ไปยังคอลัมน์ใหม่ลบการอ้างอิงไปยังคอลัมน์เก่าในแอป // TODO โดย v56: สร้างการย้ายเพื่อวางคอลัมน์เก่า

grep สำหรับ//TODO by v55เมื่อถึงเวลาที่จะปรับใช้ v55 การปรับใช้งานสร้างรันสคริปต์ที่ทำเช่นนั้นเป็นการทดสอบการรวม

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

มันน่าสนใจถ้าคุณต้องการตรวจสอบ // TODO by v54 เมื่อทำ 55 แล้วลองค้นหา code code 55 ครั้งเพียงแค่ค้นหา // TODO by จากนั้นกรองผลลัพธ์เป็น 1 ถึง 55 ตอนนี้ 56 จะไม่ทำให้เกิดความล้มเหลว

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

เรามีปัญหาที่คล้ายกันมากในทีมของเรา ในการแก้ปัญหานี้เราได้ทำการตรวจสอบการวิเคราะห์แบบคงที่ซึ่งจัดการสิ่งที่ต้องทำเหล่านี้โดยการตรวจสอบปัญหา JIRA หรือ Git Issue ที่อ้างอิง งานสร้างของเราล้มเหลวเมื่อปัญหาที่ระบุเลื่อนผ่านคอลัมน์ "ในการพัฒนา"

ดังนั้นเราสามารถมีสิ่งที่ต้องทำอย่างสะดวกสบายโดยไม่ต้องกังวลว่าพวกเขาจะถูกลืม

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

เครื่องมือนี้เรียกว่าWestieและตัวอย่างของตัวตรวจสอบปัญหา Jira นั้นอยู่ใน README.md ดูเพิ่มเติมที่ GitIssueAnalyser

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

ไม่ต้องทำ ทำมันตอนนี้.

TLDR: เขียน (และทดสอบ) สคริปต์ฐานข้อมูลของคุณทันทีไม่ใช่ในภายหลัง เพียงเขียนโค้ดเพื่อให้การประมวลผลเกิดขึ้นกับรุ่นฐานข้อมูล

ตัวอย่าง

ตัวอย่างเช่นสมมติว่าคุณต้องการที่จะเปลี่ยนชื่อคอลัมน์จากSSNการTaxIDมีความต้องการร่วมกันเมื่อไปต่างประเทศ

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

ในตัวอย่างของเราเราจะปรับใช้ build 102 (ซึ่งมีคอลัมน์ใหม่) ในขณะที่รักษาความเข้ากันได้กับ build 101 (ซึ่งไม่มี)

นี่คือขั้นตอน

1. ตั้งค่าตารางการกำหนดเวอร์ชัน

1. เพิ่มตารางเดียวเรียกว่าConfigurationมีสองคอลัมน์และNameValue

2. เพิ่มแถวที่มีName"TargetVersion" และตั้งค่าValueเป็นรุ่นของบิลด์ใหม่ที่จะนำไปใช้งาน

3. เพิ่มแถวที่มีName"CompatibleWith" และตั้งค่าเป็นValueหมายเลขเวอร์ชันต่ำสุดที่การปรับใช้จะต้องเข้ากันได้

ตรวจสอบและอัพเดตแถวเหล่านี้ก่อนการปรับใช้ทุกครั้ง

2. แก้ไขสคริปต์การปรับใช้

1. เพิ่มสคริปต์ที่สร้างคอลัมน์ใหม่ของTaxIDเคียงข้างSSNกันและเติมจากSSNคอลัมน์ ใส่รหัสนี้ในIfคำสั่งที่ตรวจสอบ TargetVersion; หากเวอร์ชันเป้าหมายต่ำเกินไป (เช่นยังTaxIDไม่จำเป็น) ให้ข้าม

   SELECT @TargetVersion = TargetVersion FROM Configuration
   IF @TargetVersion < '102' THEN RETURN
   ALTER TABLE Customer ADD COLUMN taxID VarChar(12) NOT NULL
   UPDATE Customer SET TaxID = SSN
   

2. เพิ่มสคริปต์ที่สร้างทริกเกอร์ที่เติมTaxIDเมื่อแทรกหรืออัปเดตSSNและในทางกลับกัน ใส่รหัสนี้ในIfคำสั่งที่ตรวจสอบเวอร์ชันเป้าหมายและเวอร์ชันที่เข้ากันได้ ข้ามหาก TargetVersion ต่ำเกินไป ( TaxIDไม่จำเป็น) หรือหาก CompatibleWith เวอร์ชันสูงเกินไป ( SSNไม่จำเป็นต้องใช้ฟิลด์)

   SELECT @TargetVersion  = TargetVersion,
          @CompatibleWith = CompatibleWith 
   FROM Configuration
   IF @TargetVersion  < '102' THEN RETURN
   IF @CompatibleWith > '101' THEN RETURN
   CREATE TRIGGER SSNAndTaxIDTrigger ON Customer etc.
   

3. เพิ่มสคริปต์เพื่อลบSSNคอลัมน์ ล้อมรอบด้วยIfคำสั่งที่ลบคอลัมน์เฉพาะเมื่อรุ่น CompatibleWith สูงพอ ( SSNไม่จำเป็นอีกต่อไป)

   SELECT @CompatibleWith = CompatibleWith FROM Configuration
   IF @CompatibleWith <= '101' THEN RETURN
   IF OBJECT_ID('SSNAndTaxIDTrigger') IS NOT NULL DROP TRIGGER SSNAndTaxIDTrigger
   IF EXISTS (SELECT * FROM syscolumns c JOIN sysobject o ON o.id = c.is WHERE o.Name = 'Custeomr' AND c.Name = 'SSN') BEGIN
       ALTER TABLE Customer DROP COLUMN SSN
   END
   

3. การทดสอบ

ตรวจสอบให้แน่ใจว่าได้ทดสอบการปรับใช้ของคุณด้วยการรวมกันของหมายเลขรุ่นสีน้ำเงิน / สีเขียวที่คุณต้องการให้สามารถรองรับในการผลิต คุณสามารถทดสอบได้ทันทีที่รหัสพร้อมโดยจัดการConfigurationตารางในสภาพแวดล้อม QA ของคุณ

4. ใน playbook การปรับใช้ของคุณ

เพิ่มขั้นตอนสำหรับวิศวกรเพื่ออัปเดตแถว CompatibleWith และ TargetVersion หากคุณกำลังปรับใช้เป็น Blue ให้ตั้งค่า TargetVersion เป็นหมายเลขเวอร์ชันของ Blue และ CompatibleWith version เป็นหมายเลขเวอร์ชันของ Green ย้อนกลับพวกเขาหากคุณกำลังปรับใช้สีเขียว

ผิดพลาด

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

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

ผลลัพธ์ของสิ่งนี้ทั้งหมด

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

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

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

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

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