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

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

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

มีวิธีใดบ้างในการลดบั๊กประเภทนี้ซึ่งเกิดจากการกำหนดค่าเริ่มต้นของการปรับใช้เวอร์ชันใหม่

PS: โปรดอย่าพูดถึงรายการตรวจสอบเพราะเรามีพวกเขาแล้ว ปัญหาเกี่ยวกับรายการตรวจสอบคือพวกเขาควรได้รับการปรับปรุง แต่พวกเขาจะไม่

สองสิ่ง:

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

มีสิ่งอื่น ๆ ที่สามารถทำได้

ฉันขอแนะนำให้อ่านชุดบล็อก 5 ส่วนเกี่ยวกับการปรับใช้อัตโนมัติโดย Troy Hunt เครื่องมือที่เขาใช้คือ MS stack เฉพาะ แต่แนวคิดนั้นเป็นสากล

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

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

ประการที่สองคุณต้องมี "พื้นที่จัดเตรียม" บางส่วน - อาจเป็นอะไรก็ได้ - เซิร์ฟเวอร์ในพื้นที่เซิร์ฟเวอร์คลาวด์เสมือนชั่วคราวที่คุณเพิ่งวางไข่ตั้งค่าโฮสต์เสมือนง่าย ๆ หรือแอปพลิเคชันที่กำหนดเองที่สมบูรณ์ คุณดูแลพร้อมกับแอพหลัก ความแตกต่างระหว่าง "พื้นที่การจัดเตรียม" และ "พื้นที่การพัฒนา" ของคุณคือรูปแบบที่ใกล้เคียงกว่าเดิม (หรือจำลอง) สภาพแวดล้อมการปรับใช้จริงของคุณ ตัวอย่างเช่นคุณสามารถพัฒนาบน PHP 5.3.x ด้วยโมดูล Apache แต่เนื่องจากโฮสต์ของคุณคือ PHP 5.2.x พร้อม FCGI พื้นที่การแสดงละครของคุณจะต้องเหมือนกัน

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

ในที่สุดก็รวมการเปลี่ยนแปลงพื้นที่การแสดงละครในสำเนาการปรับใช้สดของคุณ

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

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

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

นี้นำขึ้นจุดอื่น: มีการทดสอบ การทดสอบสิ่งที่ฉันเขียนเองไม่พบข้อบกพร่องมากเท่ากับเมื่อมีคนทดสอบแอปพลิเคชันของฉัน

อีกสิ่งหนึ่ง: ทำให้กระบวนการปรับใช้ของคุณเป็นแบบอัตโนมัติ ทำ db migrations ด้วย ant migrate, ปรับใช้เวอร์ชันใหม่ล่าสุดโดยอัตโนมัติจาก svn ผ่าน capistrano เป็นต้นเมื่อคุณปรับใช้บางอย่างคุณไม่ควรทำอะไรมากกว่านี้แค่คลิกและทุกอย่างก็เป็นไปโดยอัตโนมัติ โดยเฉพาะอย่างยิ่งสำหรับเว็บไซต์ที่ต้องมีการตั้งค่าบางอย่างขั้นตอนที่ต้องทำด้วยตนเองเป็นฝันร้ายและความเป็นไปได้ที่บางสิ่งผิดปกติมาก

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

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

สำหรับหลาย ๆ แอปพลิเคชันฉันยอมรับว่านี่เกินความจริง

นอกจากนี้ยังมีความซับซ้อนในการจัดการธุรกรรมใด ๆ ที่คุณต้องทำ แต่ปัญหาไม่สามารถผ่านไม่ได้

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

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

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

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

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

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

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

กล่าวโดยย่อการยอมรับหลักการผสมผสานอย่างต่อเนื่อง (CI) ที่มากขึ้นจะช่วยขจัดความเจ็บปวดจากการปล่อยการผลิต

1) นำไปใช้กับไซต์ทดสอบก่อนและทดสอบการเปลี่ยนแปลงของคุณ

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

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

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

ส่วนงาน codebase วิธีการหนึ่งที่พบบ่อยคือการแยกมันออกเป็น:

• ส่วนหลักสองสามอย่างที่เปลี่ยนช้าและใช้ร่วมกันทั่วทั้งไซต์
• หลายส่วนของใบไม้ที่อาจเปลี่ยนแปลงได้เร็วกว่า แต่แต่ละชิ้นก็มีผลกระทบกับส่วนเล็ก ๆ ของเว็บไซต์

ความเข้าใจเกี่ยวกับฐานรหัสของคุณช่วยให้คุณสามารถมุ่งเน้นการพัฒนาและการทดสอบในส่วนที่สำคัญเนื่องจากข้อบกพร่องจะมีผลกระทบที่รุนแรงที่สุด

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

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

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

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

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

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

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

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

2. ทดสอบทดสอบทดสอบ ไม่เพียงแค่ทดสอบรหัสของคุณในสภาพแวดล้อม QA ของคุณใช้สภาพแวดล้อม staging เพื่อทดสอบซอฟต์แวร์ของคุณเช่นกัน บ่อยครั้งที่มีข้อบกพร่องที่มีน้อยหรือไม่มีอะไรจะทำอย่างไรกับรหัสตัวเอง แต่มีสาเหตุหลักที่อยู่ในการกำหนดค่าของสภาพแวดล้อมของตัวเอง (หรือผสมบางอย่างของทั้งสอง) ในการค้นหาปัญหาเหล่านี้คุณจำเป็นต้องทดสอบรหัสของคุณในสภาพแวดล้อมที่สะท้อนการผลิตอย่างใกล้ชิดหรือที่เรียกว่าการจัดเตรียม

ในฐานะที่เป็นคำพูดสุดท้ายบางครั้งสิ่งที่สำคัญที่สุดไม่ใช่สิ่งที่เราทำเพื่อป้องกันสิ่งผิดพลาด แต่มันเป็นวิธีที่เราปฏิบัติตนเมื่อพวกเขาทำผิด ดังนั้นฉันคิดว่ามันเป็นสิ่งสำคัญที่จะสร้างวัฒนธรรมใน บริษัท ของคุณเกี่ยวกับความโปร่งใสในการดำเนินงาน อย่าพยายามซ่อนปัญหาจากลูกค้าไว้ล่วงหน้า ใช้ Twitter อย่างแข็งขันเพื่อให้ลูกค้าทราบว่ามีปัญหาทีมงาน ops ของคุณกำลังรับทราบและกำลังแก้ไขปัญหา ( Lighthouse ยอดเยี่ยมมากในตอนนี้!) พิจารณาการเผยแพร่หน้า "สถานะ" สำหรับบริการของคุณที่ลูกค้าสามารถอ้างอิงเพื่อดูว่ามีอะไรผิดปกติหรือไม่ ( TypePadเป็นตัวอย่างที่ยอดเยี่ยมสำหรับเรื่องนี้) บรรทัดล่างเสมอทำผิดด้านการสื่อสารมากเกินไป ลูกค้าของคุณจะขอบคุณสำหรับมัน

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

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

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