การพัฒนาบนเซิร์ฟเวอร์ที่ใช้งานจริง

วันนี้ฉันตะโกนเพื่อพัฒนาแอปพลิเคชันบนเซิร์ฟเวอร์ที่ใช้งานจริง อ้างว่า " การพัฒนาบนเซิร์ฟเวอร์ที่ใช้งานจริงไม่เป็นที่ยอมรับ - ตลอดไป! "

นี่คือสถานการณ์

1. ฉันตั้งค่าอินสแตนซ์การพัฒนา: http://example.com:3000
2. ตัวอย่างการผลิตคือ: http://example.com
3. ฉันเสร็จสมบูรณ์ในทุกการพัฒนางานของฉันในและเมื่อลูกค้ามีความยินดีกับการเปลี่ยนแปลงที่ผมย้ายพวกเขาไปยังhttp://example.com:3000http://example.com

แอปพลิเคชันที่ฉันทำงานด้วยเป็นแอพพลิเคชั่นRuby on Railsและฉันต้องบอกว่าในตอนแรกฉันพยายามตั้งค่าสภาพแวดล้อมการพัฒนาในพื้นที่ แต่ฉันก็ไม่สามารถทำงานได้ หลังจากลองไปพักหนึ่งผมก็เลิกและตัดสินใจที่จะพัฒนาบนเซิร์ฟเวอร์ที่ใช้งานจริง

อีกครั้งฉันเป็นคนงี่เง่า? อาจเป็นเช่นนั้น แต่ฉันได้ทำการพัฒนาเว็บไซต์มาสองสามปีแล้วและฉันไม่เคยเจอสถานการณ์เช่นนี้ ใครถูกและทำไม

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

1. รหัสการพัฒนาอาจทำให้เกิดลูปไม่สิ้นสุดการรั่วไหลของหน่วยความจำหรือปัญหาอื่น ๆ ที่ล็อค CPU กินหน่วยความจำทั้งหมดหรือส่งผลกระทบต่อเซิร์ฟเวอร์ในลักษณะที่จะส่งผลกระทบต่อรหัสการผลิตของคุณ
2. หากคุณต้องการเปลี่ยนแปลงองค์ประกอบของสภาพแวดล้อมเซิร์ฟเวอร์ซึ่งเป็นส่วนหนึ่งของงานพัฒนาของคุณเช่นเวอร์ชันของRubyหรือMySQLหรืออะไรก็ตามคุณจะอยู่ในรูปแบบผูกมัด

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

ธุรกิจที่แตกต่างกันมีการตอบสนองที่แตกต่างกันไป แต่โดยทั่วไปสามารถแยกย่อยได้ดังนี้

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

นี่เป็นการคำนวณขั้นสุดท้ายให้คุณ:

• การขันสกรูที่ป้องกันได้ทั้งหมดนี้มีราคาเท่าไหร่

นี่คือโครงสร้างการจัดการทั้งหมดของคุณที่มีค่าน้อยกว่าคนที่ตัดสินใจงบประมาณ ดังนั้นตะโกน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ที่เพิ่มเข้ามาอยู่ด้านปัญหาของการมีปัญหากับอินสแตนซ์การพัฒนาของคุณ: ผมเคยประสบความสำเร็จที่ยิ่งใหญ่ปรับใช้VirtualBox -based VM ที่ซ้ำกันสภาพแวดล้อมการผลิตของเรา (ไม่รวมฮาร์ดแวร์ของหลักสูตร) กับอูบุนตูเซิร์ฟเวอร์

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

อย่ายุ่งกับข้อมูลการผลิตซึ่งสามารถเกิดขึ้นได้อย่างง่ายดายมาก!

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

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

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

1. สร้างในเครื่อง
2. ผลักไปที่กล่องบางประเภทที่เลียนแบบการผลิตให้มากที่สุดเพื่อดูว่ามันเล่นได้ดีหรือเปล่า
3. อาจส่งไปที่ QA หรืออินสแตนซ์การรับรองเพื่อส่งผ่านไปยังลูกค้า / ทีม QA เพื่อตรวจสอบการเปลี่ยนแปลง
4. ผลักดันการผลิต

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

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

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

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

ในอาชีพของฉันฉันพบเพียงสองเหตุผลในการเปลี่ยนรหัสบนเซิร์ฟเวอร์ที่ใช้งานจริง:

1. ข้อบกพร่องหรือพฤติกรรมที่เกิดขึ้นที่นั่นเท่านั้นและไม่สามารถทำซ้ำได้ในสภาพแวดล้อมการพัฒนา สิ่งเหล่านี้หายาก แต่อาจน่ารำคาญและหายาก

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

ทั้งคู่เป็นผู้พัฒนาที่ดีที่สุดที่รู้จักระบบอย่างใกล้ชิด