ในฐานะนักพัฒนาฉันใช้เวลาส่วนใหญ่คิดเกี่ยวกับรหัส UI โครงสร้างข้อมูลและอื่น ๆ แต่ (ฉันยอมรับอย่างกล้าหาญ) ฉันไม่ได้พิจารณาถึงผลกระทบของแอปของฉันสำหรับ sysadmins และ DBAs จนกว่าจะถึงเวลาปรับใช้ แอป
ก่อนอื่นฉันขอโทษ ประการที่สองสิ่งที่คุณต้องการให้ฉันและนักพัฒนาอื่น ๆ ที่คุณจัดการจะทำแตกต่างกันอย่างไร สิ่งใดที่จะทำให้ชีวิตง่ายขึ้นสำหรับคุณทำให้เกิดปัญหาน้อยลงกระตุ้นให้เกิดความร่วมมือและลดปัญหาระบบขัดข้องปัญหาประสิทธิภาพและฝันร้ายของการกำหนดค่า
คำตอบ:
โปรดจำไว้ว่าใบสมัครของคุณอาจมีสถานะมากกว่าขึ้นหรือลง วาดแผนภาพสถานะ แอปพลิเคชันส่วนใหญ่มีสถานะดังนี้:
คิดว่าจะเกิดอะไรขึ้นถ้าระบบล่มระหว่างแต่ละรัฐ ดูแลระบบจะตรวจสอบและควบคุมการเปลี่ยนสถานะ?
แยกแยะ "ผู้ใช้" ออกจาก SA
"ผู้ใช้" จำเป็นต้องรู้วิธีการใช้ซอฟต์แวร์ของคุณ ผู้ใช้ไม่สนใจสิ่งต่าง ๆ เช่นวิธีการติดตั้งซอฟต์แวร์ของคุณ
SA ไม่สนใจวิธีใช้ซอฟต์แวร์ของคุณ แต่จำเป็นต้องรู้รายละเอียดที่สำคัญบางอย่างเกี่ยวกับวิธีการติดตั้งซอฟต์แวร์
เขียนเอกสารแยกต่างหากสำหรับแต่ละบทบาทรวมถึงข้อมูลที่เกี่ยวข้องสำหรับแต่ละบทบาท
หนึ่งในความปรารถนาของฉันคือการรวมข้อความที่เหมาะสมในข้อยกเว้นและรหัสข้อผิดพลาด มันทึบแสงอย่างสมบูรณ์สำหรับคนที่ไม่ได้พัฒนาแอพพลิเคชั่JimmyNotAtHomeException: it's late!น
แต่ข้อความเช่นUnable to find jimmy - initial manual call_mother procedureนี้มีประโยชน์มาก
การสื่อสารการสื่อสารการสื่อสาร ปัญหาทุกอย่างระหว่างระบบดูแลระบบและ dev สามารถติดตามได้ตลอดเวลาเนื่องจากขาดการสื่อสาร หากก่อนหน้าโครงการ sysadmins (หรือตัวแทนของมัน) และ devs มารวมกันและมีการอภิปรายกรอบที่ดี SOOOOOOOOOOOO ปัญหามากมายสามารถหลีกเลี่ยงปัญหาได้ ฉันไม่สามารถบอกคุณได้ว่ามีกี่สิ่งที่ยุ่งเหยิงเพราะคุณพัฒนาทุกคนบนกล่องเดียวในการพัฒนาเท่านั้นที่จะดูมันลงไปในเปลวไฟในแยงเพราะแอพนั้นจะถูกแยกไปยังเซิร์ฟเวอร์ App + เซิร์ฟเวอร์ DB + เซิร์ฟเวอร์อินเตอร์เฟซ ฯลฯ ความรุ่งโรจน์ที่นำหัวข้อนี้ขึ้นมา
มีส่วนร่วมกับเราในช่วงต้นของโครงการ เหมือนจริงจริงเร็วในช่วงสเปคการทำงาน
มีคนอื่นพูดถึงว่าต้องติดตั้งด้วยตนเองในพีซีทุกเครื่อง แต่จะใช้สำหรับการเปลี่ยนแปลงการกำหนดค่าและการกำหนดค่าเช่นเดียวกัน หากคุณเลือกที่จะเก็บสิ่งที่ต้องการการเชื่อมต่อสายฝั่งไคลเอ็นต์และจำเป็นที่จะต้องปรับปรุงพวกเขาเป็นประจำ, เราอาจจะต้องการที่จะฆ่าคุณ
เลือกเทคโนโลยีที่สามารถจัดการและกำหนดค่าจากส่วนกลางได้อย่างเหมาะสมด้วยเหตุผลเดียวกัน ตรวจสอบให้แน่ใจว่ามันเข้ากันได้ดีกับเครื่องมือการจัดการส่วนกลางที่เราใช้
ทดสอบโดยใช้ตัวหารร่วมที่ต่ำที่สุดเสมอ นั่นหมายถึงในฐานะที่ไม่ใช่ผู้ดูแลระบบบนระบบปฏิบัติการพื้นฐานที่สุด, ชุดโปรแกรมและการใช้งานเบราว์เซอร์ในการใช้งานทั่วไป เราไม่ชอบการอัปเกรดเบราว์เซอร์ที่จำเป็นสำหรับผู้ใช้ของเราทุกคนที่มาถึงเราในนาทีสุดท้าย
อย่าข้ามไปโทษเราเมื่อสิ่งผิดปกติ ในงานเก่าของฉันทุกครั้งที่แอพพังนักพัฒนาจะชี้ไปที่เราทันที "คุณติดตั้งแพตช์ใหม่คุณจะไม่อัปเกรดเบราว์เซอร์ความปลอดภัยของคุณแน่นเกินไป" หรืออะไรก็ตาม สิ่งนี้สร้างบรรยากาศที่เป็นอันตราย เราอยู่ด้านเดียวกันจริง ๆ และเราต้องการทำงานกับคุณเพื่อแก้ไข แต่เราไม่สามารถอยู่ในสถานการณ์แบบนั้นได้
อย่าเป็นชนชั้นนำ
"อย่าเสียเวลาของฉันเพื่อนของคุณเพียงแค่ดูแลระบบ dogsbody. ฉันเขียนซอฟแวร์และคุณเพียงบริการไอทีดังนั้นเพียงแค่ปิดขึ้นกับความกังวลเล็ก ๆ น้อย ๆ ของคุณและทำตามที่ฉันบอกว่าตกลง.?"
ผู้พัฒนาพูดคำเหล่านั้นกับฉันหนึ่งครั้ง (1) ในอีเมล สำเนาถึงกลุ่มการแจกจ่ายขนาดใหญ่ ความหมายชัดเจน: ในฐานะนักพัฒนาเขาเป็นเจ้านายและเป็นเจ้าแห่งจักรวาลซอฟต์แวร์ทั้งหมด และฉันก็เป็นเพียงผู้ทำงานกลางวันที่จ้างให้จัดการงานเล็ก ๆ น้อย ๆ ให้เขาเสียเวลาอันมีค่าของเขาต่อไป แน่นอนว่านี่เป็นตัวอย่างที่เลวร้ายที่สุด แต่คุณรู้ไหมฉันเคยได้ยินเสียงสะท้อนที่รุนแรงและอ่อนแอของความคิดเห็นนั้นจากนักพัฒนาหลายคนทั้งก่อนและหลัง (2)
คุณอาจทำเงินได้มากกว่าฉัน (แต่อย่าทึกทักเอาเอง!) แต่ต้องใช้ทีมในการสร้างใช้งานและบำรุงรักษาระบบที่ผู้ใช้ของเราเชื่อถือ ท้ายที่สุดเราทุกคนรับใช้พวกเขา
ฉันเข้าใจว่างานและทักษะของคุณแตกต่างจากของฉัน ฉันเคารพความสามารถของคุณ ฉันหวังว่าคุณจะตอบคำถามของฉันแม้ว่าพวกเขาจะดูเรียบง่ายและโง่เง่าก็ตาม ฉันจะส่งคืนความสุภาพนี้อย่างมีความสุข!
ฉันไม่ได้บ้าพลังการเดินทางเนื่องจาก devs ที่ไม่ดี (หรือไม่สนใจ) ได้พูดและคิดและโพสต์ในฟอรัมต่างๆ แต่ข้อกังวลของฉันแตกต่างจากของคุณและคำถามและข้อเสนอแนะของฉันไม่ได้ให้บริการอัตตาของฉัน อันที่จริงงานของฉันคือทำให้คุณดูดีขึ้นโดยทำให้แอปของคุณอยู่ในสภาพที่ใช้งานได้ดีที่สุดพร้อมใช้งานและตอบสนองต่อผู้ใช้ทุกคน ในการทำเช่นนั้นฉันต้องทำให้ส่วนที่เหลือของเครือข่ายและระบบยังทำงานในรูปแบบสุดยอด
ฉันรู้ว่าคุณเคยเจอคนโง่เขลาพลังบ้าคลั่งและ / หรือเพียงแค่ผู้ดูแลระบบขี้เกียจธรรมดาในอดีต ฉันพยายามที่จะไม่เป็นหนึ่งและไม่เหมือนอย่างใดอย่างหนึ่ง หากคุณออกจากห้องสำหรับความเป็นไปได้นี้และรับทราบเมื่อคุณเห็นมันฉันค่อนข้างแน่ใจว่าคุณจะได้รับสิ่งที่คุณต้องการในขณะที่คนอื่น ๆ ยังคงเป็นไอที่ไอว่า assholes ของพวกเขาคืออะไร
(1) เขายืนยันด้วยว่าโปรแกรมของเขา (เครื่องมือสำหรับการเขียนและการจัดการข้อกำหนดซอฟต์แวร์) จำเป็นต้องมีสิทธิ์ผู้ดูแลระบบโดเมนในการติดตั้งและเรียกใช้ มันเป็นความเสี่ยงด้านความปลอดภัยที่สำคัญ
(2) ฉันได้ทำงานกับนักพัฒนาที่ยอดเยี่ยมหลายคนที่สามารถสอนเมื่อจำเป็นและเรียนรู้เมื่อจำเป็น
เคารพว่า sysadmins มีงานต้องทำและให้พวกเขาทำงานของพวกเขา บริษัท จำนวนมากมีผู้ดูแลระบบที่ไร้ความสามารถและมักจะไม่เป็นจริง แต่ฉันได้เห็นนักพัฒนาที่หยิ่งเพิกเฉยต่อคำแนะนำของกลุ่มระบบแม้หลังจากที่ผู้ดูแลระบบได้พิสูจน์ความสามารถของพวกเขาแล้ว
อภิปรายการออกแบบระบบใหม่ด้วย sysadmins มักจะมีความเข้าใจที่มีคุณค่า นักพัฒนามักจะพิจารณาการหารือกับ sysadmins และให้ความต้องการเริ่มต้นเป็น "การเพิ่มประสิทธิภาพก่อนวัยอันควร" ฉันเห็นหัวหน้ากลุ่มพัฒนาบอกว่ามันเป็นการเสียเวลาที่จะพูดคุยเกี่ยวกับข้อกำหนดสำหรับเซิร์ฟเวอร์ฐานข้อมูลใหม่ที่มี sysadmins และ DBAs แม้ว่าจะอธิบายว่ามันเป็นภาระการเขียนหรือการอ่านมากหรือไม่ก็ตาม ต้องการพื้นที่เก็บข้อมูลเท่าใด
หารือเกี่ยวกับปัญหาประสิทธิภาพการทำงานกับ sysadmins sysadmins ที่ซื่อสัตย์เท่านั้นที่สามารถตีความการวัดประสิทธิภาพบนระบบได้อย่างเหมาะสม ฉันเคยเห็นผู้พัฒนาตัดสินใจว่า Linux จะรั่วหน่วยความจำเสมอเพราะหน่วยความจำที่รายงานโดย "free" จะลดลงเสมอแม้หลังจากที่อธิบายการส่งออกของ "ฟรี" เป็นครั้งที่ 10 ก็ตาม
อย่าทำข้อสรุปโดยไม่ปรึกษากับผู้ดูแลระบบ ฉันเคยเห็นนักพัฒนาติดอยู่กับทฤษฎีเช่น "ฐานข้อมูลมักจะ diskbound" (พวกเขาไม่รู้ว่ามี iostat อยู่), "RAID 5 เร็วกว่าสำหรับปริมาณงานที่ทำธุรกรรม" (อิงจากความทรงจำของระบบฐานข้อมูลเดียวที่ถูกย้าย จากแพลตฟอร์มฮาร์ดแวร์หนึ่งไปสู่อีกแพลตฟอร์มหนึ่ง - เป็นภาระงานที่อ่านได้อย่างเข้มข้นโซลูชั่น RAID5 มีไดรฟ์มากขึ้นและเร็วขึ้นกระจายไปทั่วคอนโทรลเลอร์มากขึ้น แต่พวกเขาลืมรายละเอียดเหล่านี้และจดจำเฉพาะข้อสรุปเท่านั้น)
อย่าออกแบบวิธีแก้ไขปัญหาของระบบโดยไม่ปรึกษากับ sysadmins ฉันทำงานในสภาพแวดล้อมทางพยาธิสภาพเดียวที่นักพัฒนาจะออกแบบวิธีแก้ปัญหาและขอความช่วยเหลือในการปรับใช้เล็กน้อย สมาชิกของกลุ่ม Unix นอกเหนือจากตัวฉันเองหัวหน้ากลุ่ม Unix และหัวหน้าของเขาต้องการที่จะปฏิบัติต่อนักพัฒนาในฐานะ "ลูกค้า" ไม่ใช่เพื่อนร่วมงานที่พยายามสร้างฟังก์ชั่นโครงสร้างพื้นฐานโดยรวม ลูกค้าที่ถูกต้องเสมอหมายถึงไม่ตั้งคำถามกับสิ่งที่พวกเขาทำหรือทำไม ฉันเป็นคนเดียวที่จะยืนยันว่ามีปัญหาอธิบายเพื่อให้สามารถแก้ไขปัญหาได้อย่างถูกต้อง อย่ากระทำการใด ๆ ที่สร้างสภาพแวดล้อมทางพยาธิวิทยาเช่นนี้ มันไม่ได้ส่งผลประโยชน์สุทธิ แต่ผู้จัดการระบบจะทำหน้าที่ป้องกันและทุกคนจะต้องทนทุกข์ทรมาน
คุณไม่ได้อยู่โรงเรียนอีกแล้ว สิ่งเหล่านี้เป็นระบบในโลกแห่งความเป็นจริงและพวกมันไม่ได้ทำหน้าที่ในอุดมคติ ตัวอย่างเช่นไม่ใช่ทุกอย่างที่มีเวลาแฝงเป็นศูนย์ เมื่อดูแลระบบเตือนคุณว่าโซลูชันการทำคลัสเตอร์เป็นเพียงเพื่อจุดประสงค์ทางการเมืองเท่านั้นและความซับซ้อนที่เพิ่มขึ้นของระบบจะลดความน่าเชื่อถือโดยรวมให้จริงจัง คุณต้องออกแบบโหมดความล้มเหลวในโลกแห่งความเป็นจริงตัวอย่างเช่นเมื่อเซิร์ฟเวอร์ของคุณกำลังพูดถึงผ่าน TCP การเชื่อมต่อจะไม่ถูกรีเซ็ตสำหรับคุณ Sysadmins เข้าใจโหมดความล้มเหลวในโลกแห่งความจริง
ทั้งฟังสิ่งที่ดูแลระบบของคุณบอกคุณหรือบ่นกับผู้บริหารว่าดูแลระบบของคุณไร้ความสามารถและต้องถูกไล่ออก การไม่ดูแลระบบของคุณไม่สมเหตุสมผล
พิจารณาว่าคุณจะปรับใช้แอปพลิเคชันของคุณอย่างไร ตระหนักว่าการพูดคุยเรื่องนี้กับ sysadmins ของคุณสมเหตุสมผลแล้ว หากคุณมีเซิร์ฟเวอร์ 100 เซิร์ฟเวอร์ที่เหมือนกันแตกต่างกันไปตามไฟล์การกำหนดค่าเดียวคุณอาจต้องการพิจารณาจัดเก็บสำเนาต้นฉบับของไฟล์กำหนดค่าเหล่านี้ไว้ในตำแหน่งส่วนกลาง ตระหนักดีว่าทุกคนนั้นดีกว่ากันมากหากแอปพลิเคชันของคุณสามารถปรับใช้ใหม่ได้ง่าย หากมีปัญหาเกี่ยวกับระบบคุณควรจะปรับใช้อีกครั้งภายในไม่กี่นาทีเพื่อสำรองหรือรออายุในขณะที่คนที่ชำรุดได้รับการซ่อมแซม? หากคุณสามารถปรับใช้แอปพลิเคชันของคุณใหม่ได้ระบบปฏิบัติการสามารถอัปเกรดได้ง่ายและปลอดภัยยิ่งขึ้น คุณอาจสนใจเรื่องนี้ในอนาคต
หากคุณมีปัญหาที่คุณคิดว่าอาจเกิดจากระบบปฏิบัติการคุณควรเรียกผู้ดูแลระบบทันทีเพื่อตรวจสอบ แต่หลังจากการตรวจสอบคร่าวๆไม่พบสิ่งใดคุณมีหน้าที่อธิบายปัญหา
ทำความเข้าใจว่ามีความแตกต่างระหว่าง "การตอบสนองช้า" และ "ไม่ตอบสนองเลย"
กำหนดค่าและจัดวางสิ่งต่าง ๆ ด้วยวิธีที่คาดการณ์ได้ด้วยวิธีที่เปลี่ยนแปลงได้สำหรับระบบปฏิบัติการ (en) ที่คุณกำลังพัฒนา นี่หมายถึงทุกสิ่ง ตัวอย่างเช่น: OpenLDAP มีวิธีแปลก ๆ ในการทำ loglevels; เซิร์ฟเวอร์ IMAP บางตัวไม่มีแม้กระทั่งไฟล์กำหนดค่า แต่ต้องมีตัวเลือกที่คอมไพล์ด้วย แพคเกจบางอย่างต้องการสิ่งที่พวกเขาจะอยู่ในเส้นทางไดเรกทอรีหนึ่งซึ่งย่อมจะแบ่งการประชุมของระบบปฏิบัติการโดยเฉพาะอย่างหลีกเลี่ยงไม่ได้ สิ่งเหล่านี้ล้วนเป็นหูดในการกำหนดค่าปกติของฉัน
เป็นกฎทั่วไป แต่อย่าคิดว่าคุณเป็นคนพิเศษและมีความสุขมากที่ได้หยุดการประชุมทั่วไปว่าแพคเกจซอฟต์แวร์ทำงานโดยทั่วไปบนแพลตฟอร์มของคุณได้อย่างไรเว้นแต่จะมีเหตุผลที่ดีเป็นอย่างยิ่งที่ซอฟต์แวร์ของคุณต้องการ "ฉันรู้สึกอย่างยิ่งว่าควรเป็นเช่นนั้น" ไม่ดีพอที่จะทำให้การตั้งค่าปกติของทุกคนหยุดชะงัก จะต้องมีเหตุผลที่เชื่อมต่อกับฟังก์ชั่นซอฟต์แวร์ของคุณพยายามที่จะดำเนินการ
เมื่อมีการสื่อสารระหว่างเซิร์ฟเวอร์ที่เกี่ยวข้องกับแอพโปรดรวม sysadmin อย่างน้อยหนึ่งรายการในขั้นตอนการออกแบบ นอกจากนี้เอกสารที่ชัดเจนเกี่ยวกับการพึ่งพาบริการอื่น ๆ : SQL, SMTP, HTTP, ฯลฯ ... อย่าทำให้เราเดาว่าคุณกำลังทำอะไรอยู่หรือเราไม่สามารถช่วยคุณได้เมื่อมีบางอย่างไม่ทำงานอย่างที่คุณคาดไว้
โปรดทำให้สามารถปรับใช้ซอฟต์แวร์ของคุณในระบบหลายสิบหรือหลายร้อยระบบในรูปแบบอัตโนมัติ หากองค์กรต้องการแพคเกจซอฟต์แวร์ sysadmins แทบไม่มีเวลาติดตั้งด้วยตนเองในทุก ๆ กล่อง หากไฟล์นั้นจำเป็นต้องมีข้อมูลสิทธิ์ใช้งานการจัดทำเอกสารว่าจะให้ประโยชน์อย่างไร
Adobe ได้มีการติดตั้งบางอย่างที่ในอดีตเป็นความเจ็บปวดที่แท้จริงในการทำงานร่วมกับ ; โปรดตั้งเป้าหมายให้สูงกว่านั้น!
คิดเกี่ยวกับการปรับขนาดจากวันแรก Sysadmins สามารถทำสิ่งมหัศจรรย์ได้โดยการขว้างเงิน / ฮาร์ดแวร์ไปที่ปัญหาด้านประสิทธิภาพ แต่บางครั้งก็ไม่มีสิ่งเหล่านี้ที่จะช่วยได้ - โดยเฉพาะอย่างยิ่งคิดเกี่ยวกับการล็อค - บางครั้งคุณไม่สามารถซื้อตัวคุณเองจากปัญหาการล็อค ขอบคุณที่ถามว่า :)
โอ้และลองเป็น 64- บิตที่เป็นไปได้และแบบมัลติเธรดด้วย :)
ออกแบบเพื่อการปฏิบัติงาน
เหนือสิ่งอื่นใดที่นี่ ...
แม้ว่าจะไม่สมจริงมันจะมีประโยชน์หากนักพัฒนาถูกบังคับให้ทำงานในระบบการดูแลระบบหรือบทบาท dba ก่อนที่จะถูกปล่อยออกมาบนโลกใบนี้
แอพพลิเคชั่นพิเศษมากมายที่ฉันจัดการไม่มีความหมายใด ๆ เกี่ยวกับการติดตั้งในสภาพแวดล้อมที่มีการจัดการหรือกระทำการออกแบบฐานข้อมูลที่โหดร้าย
1) ไฟล์บันทึกที่บันทึกข้อผิดพลาดโดยละเอียด หรือระบบติดตามข้อผิดพลาดที่ดีเช่น ELMAH
2) เอกสารรายละเอียดสำหรับการติดตั้งการใช้งานและคำแนะนำ SA
3) บวกกับสิ่งที่กล่าวข้างต้นจาก SA ที่น่าทึ่งอื่น ๆ :)
นั่นคือทั้งหมดที่ฉันสามารถคิดได้ในขณะนี้
หนังสือปล่อยมัน! มีเรื่องราวสยองขวัญเกี่ยวกับสิ่งที่ผิดพลาดในการผลิต การอ่านสามารถให้แรงบันดาลใจ / แนวคิดในการออกแบบโดยคำนึงถึงการดำเนินงาน (เขียนโดย Michael Nygard ผู้ซึ่งทำงานทั้งในด้านการพัฒนาและการปฏิบัติการ)
จากประสบการณ์ของฉันสิ่งที่สร้างความแตกต่างได้มากที่สุดคือถ้านักพัฒนาคิดเกี่ยวกับการปรับใช้ตั้งแต่วันที่ 1 ทันทีที่คุณเริ่มคิดคุณลักษณะใหม่ในสภาพแวดล้อมการผลิต / ลูกค้าให้เริ่มคิดว่าจะปรับใช้อย่างไร สภาพแวดล้อมและวิธีการทำงาน
เมื่อพวกเขาเข้าสู่กระบวนการพัฒนามันยังไม่สายเกินไป แต่อาจใช้เวลาสักครู่ก่อนที่พวกเขาจะสามารถเปลี่ยนมุมมองของพวกเขาไปได้ไกล พวกเขาไม่ได้ตระหนักว่าพวกเขากำลังดู codebase อย่างเป็นนามธรรมจนกระทั่งถูกบังคับให้เผชิญหน้า ในความคิดของพวกเขามันเป็นเพียง "องค์ประกอบ" สิ่งที่น่าสนใจเป็นพิเศษคือวิธีการปรับใช้กับสภาพแวดล้อมที่มีอยู่ก่อนใช้งานซอฟต์แวร์รุ่นก่อนหน้า (หรือเก่ากว่า!) การอภิปรายการปรับใช้สามารถมีผลกระทบอย่างมีนัยสำคัญเกี่ยวกับวิธีการปรับสถาปัตยกรรมเพื่อรองรับคุณสมบัติใหม่
สิ่งที่ฉันชอบที่ฉันยังไม่เคยเห็นสามารถกำหนดค่าได้ หากคุณมีแอพที่ใช้ไฟล์ปรับแต่งประเภทใดก็ได้ให้ตั้งค่าทุกอย่างได้
ที่ บริษัท ของฉันฉันเขียนแอพง่าย ๆ ที่จะส่งออกฐานข้อมูลส่วนหนึ่ง สัปดาห์หน้าฉันเขียนใหม่เพื่อให้ปิดส่วนเล็ก ๆ ทุกสัปดาห์ตั้งแต่นั้นฉันต้องเขียนชิ้นส่วนใหม่และสร้างใหม่เพื่อเปลี่ยนคุณสมบัติเล็ก ๆ ฉันเพิ่งเพิ่มไฟล์ config xml และตอนนี้มันเป็นวิธีที่ง่ายต่อการปรับใช้อีกครั้ง
ฉันรักไฟล์กำหนดค่า
ฉันหวังว่านักพัฒนาจะมีการแยกออกจากงาน QA ที่ดีขึ้น ฉันคิดว่ามันดีเมื่อผู้พัฒนาสามารถสร้างกรณีทดสอบหน่วยสำหรับโครงการที่เขา / เธอทำงาน แต่มันจะดีถ้าการทดสอบเหล่านั้นถูกส่งผ่านไปยัง QA ในความเป็นจริงมันดีเมื่อนักพัฒนาให้ความช่วยเหลือเล็กน้อยกับวิศวกร QA เพราะประโยชน์ DEV ในท้ายที่สุด
ตรวจสอบให้แน่ใจว่ารองรับได้: นอกเหนือจากทุกอย่างที่กล่าวถึงที่นี่ดูโพสต์นี้บน SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- เอกสาร /