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

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

ฉันต้องการให้พฤติกรรมนี้ถูกลงโทษอย่างใดหรือทำให้ไม่เป็นที่พอใจมากที่สุด

ก่อนที่ฉันจะเริ่มต้น บริษัท กำลังปรับใช้โดยใช้วิธีการโบราณเช่น FTP และไม่มีการควบคุมเวอร์ชัน

ฉันบังคับให้พวกเขา / เราใช้ Git, Bitbucket, Dploy.io และ HipChat การปรับใช้นั้นไม่อัตโนมัติมีคนเข้าสู่ระบบเพื่อ dply.io และกดปุ่มปรับใช้

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

คุณต้องมีกระบวนการประกันคุณภาพ (QA) ที่เหมาะสม

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

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

เมื่อคุณไม่สามารถโน้มน้าวให้ฝ่ายบริหารจ้างผู้อื่นให้ทำ QA ของคุณได้บางทีคุณอาจมีบทบาทหนึ่งในอีกฝ่ายหนึ่ง ฉันไม่เคยทำงานกับ diploy.io แต่ระบบการสร้างอัตโนมัติบางตัวสามารถกำหนดค่าได้ในลักษณะที่ผู้ใช้สามารถปรับใช้ทั้งจากการพัฒนาไปจนถึงการจัดเตรียมและจากการเตรียมการไปจนถึงการผลิต แต่ไม่ได้ทำทั้งสองอย่างสำหรับการสร้างเดียวกัน จำเป็น (แต่ต้องแน่ใจว่าคุณมีคนสำรองข้อมูลบางครั้งในกรณีที่คุณขาดไป)

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

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

ฉันต้องการให้พฤติกรรมนี้ถูกลงโทษอย่างใดหรือทำให้ไม่เป็นที่พอใจมากที่สุด

คุณสามารถมีชุดทดสอบ (คุณได้มีหนึ่งในบรรดาใช่ไหม?) Looks like $username is testing on prod, watch outรวมถึงการตรวจสอบที่กำหนดถ้าคุณอยู่ในเซิร์ฟเวอร์การผลิตและถ้ามันไม่ได้ส่งให้ทุกคนในสำนักงานอีเมลแจ้งว่า บางทีการที่เพื่อนร่วมงานของคุณน่าอับอายต่อสาธารณะอาจไม่เป็นที่พอใจ หรือคุณสามารถสร้างข้อ จำกัด ทางเทคนิคเช่นห้ามทีมของคุณไม่ให้ดูที่แยง (ซึ่งคุณสามารถยกได้ แต่คุณต้องปรับให้เหมาะสม)

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

แน่นอนสิ่งที่คุณต้องการไม่ใช่เพื่อให้พฤติกรรมนี้ถูกลงโทษ แต่เพื่อให้หยุด ?

ฉันบังคับให้พวกเขา / เราใช้ [... ]

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

ดังนั้นเริ่มต้นด้วยการสนทนา

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

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

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

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

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

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

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

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

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

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

นี่ไม่ใช่เรื่องแปลกโดยเฉพาะในทีมเล็ก ๆ อย่าทำเรื่องใหญ่ แต่ทำกฎอย่างไม่เป็นทางการ:

ทำลายการสร้างนำโดนัท

อย่างใดอย่างหนึ่ง 1) คุณจะได้รับโดนัทสองครั้งต่อสัปดาห์หรือ 2) พวกเขาจะยึดมั่นในมาตรฐาน

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

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

ตอนนี้ฉันจะบังคับพวกเขาอย่างไร ...

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

ฉันต้องการให้พฤติกรรมนี้ถูกลงโทษอย่างใดหรือทำให้ไม่เป็นที่พอใจมากที่สุด

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

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

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

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

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

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

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

นี่คือการฝึกการจัดการการเปลี่ยนแปลง

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

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

ตั้งค่ากระบวนการย้อนหลังเป็นประจำ (ตัวอย่างเช่นทุกสัปดาห์) มีทีมงานทั้งหมด:

• ระบุปัญหา
• แนวคิดอาสาสมัครเพื่อปรับปรุงการปฏิบัติงาน
• มีส่วนร่วมในการดำเนินการตามแนวทางเหล่านั้น

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

ฉันคิดว่าคุณพบปัญหาสองสามข้อ:

1. ดูเหมือนว่ารหัสใด ๆ ที่ได้รับการตรวจสอบสามารถถูกผลักไปยังการผลิตโดยผู้ที่มีสิทธิ์ในการตรวจสอบรหัส

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

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

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

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

2. ดูเหมือนว่าคุณอาจไม่ได้กำหนดมาตรฐาน / หลักการพัฒนาที่กำหนดไว้อย่างชัดเจน

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

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

คุณควรรวมกระบวนการตรวจสอบการรวมอย่างต่อเนื่องเข้ากับ บริษัท ใน บริษัท Bitbucket ทำให้ง่าย

และ +1 ไปยังเซิร์ฟเวอร์ dev ที่ผู้ใช้รายอื่นแนะนำ

อย่าหยาบคายกับเขามันจะทำร้ายความสัมพันธ์ในการทำงานของคุณเท่านั้น