รายงานจะพูดถึงแนวทางปฏิบัติบางประการของ DevOps แต่จากมุมมองของนักพัฒนา โดยปกติแล้ว วิศวกรทุกคนที่เข้าร่วม DevOps จะมีประสบการณ์ด้านการบริหารมาหลายปีแล้ว แต่นี่ไม่ได้หมายความว่าไม่มีที่สำหรับนักพัฒนาที่นี่ บ่อยกว่านั้น นักพัฒนายุ่งอยู่กับการแก้ไข “ข้อผิดพลาดที่สำคัญเร่งด่วนถัดไปของวัน” และพวกเขาไม่มีเวลาแม้แต่จะดูฟิลด์ DevOps อย่างรวดเร็วด้วยซ้ำ ตามความเข้าใจของผู้เขียน DevOps ประการแรกคือสามัญสำนึก ประการที่สอง เป็นโอกาสที่จะมีประสิทธิภาพมากขึ้น หากคุณเป็นนักพัฒนา มีสามัญสำนึก และต้องการมีประสิทธิภาพมากขึ้นในฐานะผู้เล่นในทีม รายงานนี้เหมาะสำหรับคุณ
ให้ฉันแนะนำตัวเองฉันยอมรับอย่างเต็มที่ว่ามีคนในห้องไม่รู้จักฉัน ฉันชื่อ Anton Boyko เป็น MVP ของ Microsoft Azure เอ็มวีพีคืออะไร? นี่คือ Model-View-Presenter Model-View-Presenter คือฉันเอง
นอกจากนี้ ปัจจุบันฉันดำรงตำแหน่งสถาปนิกด้านโซลูชันที่ Ciklum และเมื่อไม่นานมานี้ ฉันซื้อโดเมนที่สวยงามเช่นนี้ให้กับตัวเอง และได้อัปเดตอีเมลซึ่งโดยปกติจะแสดงในงานนำเสนอ คุณสามารถเขียนถึงฉันได้ที่: me [dog] byokoant.pro คุณสามารถส่งอีเมลถึงฉันพร้อมคำถาม ฉันมักจะตอบพวกเขา สิ่งเดียวคือฉันไม่ต้องการรับคำถามทางอีเมลที่เกี่ยวข้องกับสองหัวข้อ: การเมืองและศาสนา คุณสามารถเขียนถึงฉันเกี่ยวกับเรื่องอื่นๆ ทางอีเมล เวลาผ่านไปฉันจะตอบ
คำไม่กี่คำเกี่ยวกับตัวคุณ:
- ฉันอยู่ในวงการนี้มา 10 ปีแล้ว
- ฉันทำงานที่ไมโครซอฟต์
- ฉันเป็นบิดาผู้ก่อตั้งชุมชน Azure ของยูเครน ซึ่งเราก่อตั้งขึ้นที่ไหนสักแห่งในปี 2014 และเรายังคงมีมันอยู่และกำลังพัฒนามันอยู่
- ฉันยังเป็นบิดาของผู้ก่อตั้งการประชุม Azure ซึ่งเราเป็นเจ้าภาพในยูเครนด้วย
- ฉันยังช่วยจัดงาน Global Azure Bootcamp ในเคียฟด้วย
- อย่างที่ฉันบอกไป ฉันเป็น Microsoft Azure MVP
- ฉันพูดในที่ประชุมค่อนข้างบ่อย ฉันชอบพูดในที่ประชุมมาก ในปีที่ผ่านมาฉันสามารถแสดงได้ประมาณ 40 ครั้ง หากคุณผ่านยูเครน เบลารุส โปแลนด์ บัลแกเรีย สวีเดน เดนมาร์ก เนเธอร์แลนด์ สเปน หรือให้หรือรับประเทศอื่นในยุโรป ก็ค่อนข้างเป็นไปได้ที่เมื่อคุณไปการประชุมที่มีธีมคลาวด์อยู่ในสตรีม คุณอาจเห็นฉันอยู่ในรายชื่อวิทยากร
- ฉันเป็นแฟนสตาร์เทรคด้วย
เรามาพูดถึง Agenda กันสักหน่อย วาระของเรานั้นง่ายมาก:
- เราจะพูดถึงว่า DevOps คืออะไร มาคุยกันว่าทำไมสิ่งนี้ถึงสำคัญ ก่อนหน้านี้ DevOps เป็นคีย์เวิร์ดที่คุณเขียนไว้ในเรซูเม่ของคุณ และได้รับเงินเดือน +$500 ทันที ตอนนี้คุณต้องเขียนบล็อกเชนในเรซูเม่ของคุณเพื่อรับ +500 ดอลลาร์จากเงินเดือนของคุณ
- จากนั้นเมื่อเราเข้าใจเพียงเล็กน้อยเกี่ยวกับสิ่งนี้ เราจะพูดถึงแนวทางปฏิบัติของ DevOps แต่ไม่มากนักในบริบทของ DevOps โดยทั่วไป แต่เกี่ยวกับแนวทางปฏิบัติ DevOps ที่อาจเป็นที่สนใจของนักพัฒนา ฉันจะบอกคุณว่าทำไมพวกเขาถึงสนใจคุณ ฉันจะบอกคุณว่าทำไมคุณควรทำเช่นนี้ และวิธีที่จะช่วยให้คุณรู้สึกเจ็บปวดน้อยลง
ภาพแบบดั้งเดิมที่หลายคนแสดง นี่คือสิ่งที่เกิดขึ้นในหลายโครงการ นี่คือเวลาที่เรามีแผนกพัฒนาและปฏิบัติการที่สนับสนุนซอฟต์แวร์ของเรา และหน่วยงานเหล่านี้ไม่ได้สื่อสารกัน
บางที หากคุณไม่สามารถรู้สึกได้ชัดเจนนักใน DevOps และแผนกปฏิบัติการ คุณสามารถเปรียบเทียบกับแผนก Dev และ QA ได้ มีคนพัฒนาซอฟต์แวร์ และมีคน QA ที่ไม่ดีในมุมมองของนักพัฒนา ตัวอย่างเช่น ฉันคอมมิตโค้ดที่ยอดเยี่ยมของฉันไปที่ Repository และมีคนโกงนั่งอยู่ที่นั่นและส่งคืนโค้ดนี้ให้ฉันและบอกว่าโค้ดของคุณไม่ดี
ทั้งหมดนี้เกิดขึ้นเพราะผู้คนไม่สื่อสารกัน และพวกเขาก็โยนพัสดุ แอปพลิเคชั่นให้กันผ่านกำแพงแห่งความเข้าใจผิด และพยายามทำอะไรบางอย่างกับพวกมัน
กำแพงนี้เองที่วัฒนธรรม DevOps ได้รับการออกแบบมาเพื่อทำลาย เช่น บังคับให้ผู้คนสื่อสารกัน และอย่างน้อยก็เข้าใจว่าแต่ละคนในโครงการทำอะไร และเหตุใดงานของพวกเขาจึงมีความสำคัญ
และเมื่อเราพูดถึง DevOps จะมีคนบอกคุณว่า DevOps เกิดขึ้นเมื่อโปรเจ็กต์มีการบูรณาการอย่างต่อเนื่อง บางคนจะบอกว่า DevOps คือถ้าโครงการใช้แนวทางปฏิบัติ "โครงสร้างพื้นฐานเป็นโค้ด" บางคนจะบอกว่าขั้นตอนแรกใน DevOps คือการแตกแขนงฟีเจอร์และแฟล็กฟีเจอร์
โดยพื้นฐานแล้วทั้งหมดนี้เป็นจริงในแบบของตัวเอง แต่นี่เป็นเพียงแนวทางปฏิบัติขั้นสูงสุดที่เรามี ก่อนที่จะไปยังแนวทางปฏิบัติเหล่านี้ ฉันขอแนะนำให้ดูสไลด์นี้ ซึ่งแสดงขั้นตอน 3 ขั้นตอนในการนำวิธี Dev-Ops ไปใช้ในโครงการของคุณในบริษัทของคุณ
สไลด์นี้ยังมีชื่ออย่างไม่เป็นทางการอีกชื่อหนึ่งด้วย คุณสามารถค้นหาทางออนไลน์เพื่อดูว่า 3 Musketeers แห่ง DevOps คืออะไร เป็นไปได้ว่าคุณจะพบบทความนี้ ทำไมต้อง 3 ทหารเสือ? ด้านล่างนี้ระบุ: ผู้คน กระบวนการ และผลิตภัณฑ์ เช่น PPP – ปอร์ธอส ปอร์ธอส และปอร์ธอส นี่คือ 3 ทหารเสือแห่ง DevOps บทความนี้จะอธิบายรายละเอียดเพิ่มเติมว่าเหตุใดจึงสำคัญและเกี่ยวข้องกับอะไร
เมื่อคุณเริ่มนำวัฒนธรรม DevOps ไปใช้ สิ่งที่สำคัญมากคือจะต้องนำไปปฏิบัติตามลำดับต่อไปนี้
ขั้นแรกคุณต้องพูดคุยกับผู้คน และคุณต้องอธิบายให้คนอื่นฟังว่ามันคืออะไรและพวกเขาจะได้รับประโยชน์จากมันได้อย่างไร
การประชุมของเราชื่อ DotNet Fest และตามที่ผู้จัดงานบอกฉัน เราเชิญผู้ชมที่เป็นนักพัฒนามาที่นี่เป็นหลัก ดังนั้นฉันหวังว่าคนส่วนใหญ่ในฮอลล์จะมีส่วนร่วมในการพัฒนา
เราจะพูดถึงผู้คน เราจะพูดถึงสิ่งที่นักพัฒนาต้องการทำทุกวัน พวกเขาต้องการอะไรมากที่สุด? พวกเขาต้องการเขียนโค้ดใหม่ ใช้เฟรมเวิร์กแบบใหม่ สร้างฟีเจอร์ใหม่ นักพัฒนาต้องการอะไรน้อยที่สุด? แก้ไขข้อผิดพลาดเก่า ฉันหวังว่าคุณจะเห็นด้วยกับฉัน นี่คือสิ่งที่นักพัฒนาต้องการ พวกเขาต้องการเขียนคุณสมบัติใหม่ พวกเขาไม่ต้องการแก้ไขข้อบกพร่อง
จำนวนข้อบกพร่องที่นักพัฒนาเฉพาะรายสร้างขึ้นนั้นขึ้นอยู่กับว่าแขนของเขาเหยียดตรงแค่ไหน และแมลงจะเติบโตจากไหล่ของเขามากน้อยเพียงใด ไม่ใช่จากกระเป๋าก้นของเขา แต่อย่างไรก็ตาม เมื่อเรามีโปรเจ็กต์ขนาดใหญ่ บางครั้งมันเกิดขึ้นจนไม่สามารถติดตามทุกอย่างได้ ดังนั้นจึงเป็นการดีสำหรับเราที่จะใช้แนวทางบางอย่างที่จะช่วยให้เราเขียนโค้ดที่เสถียรและมีคุณภาพสูงขึ้น
QA ต้องการอะไรมากที่สุด? ฉันไม่รู้ว่าพวกเขาอยู่ในห้องโถงหรือเปล่า มันยากสำหรับฉันที่จะบอกว่าฉันต้องการ QA เพราะฉันไม่เคยมีมาก่อน และไม่มีความผิดกับผู้ชายก็จะบอกว่าฉันหวังว่าจะไม่มีวันทำ แต่ไม่ใช่ด้วยเหตุผลที่ฉันคิดว่างานของพวกเขาไร้ความหมายและไร้ประโยชน์ แต่เพราะฉันไม่คิดว่าตัวเองเป็นคนที่สามารถทำงานได้อย่างมีประสิทธิภาพดังนั้นฉันจึงไม่พยายามทำมันด้วยซ้ำ แต่จากสิ่งที่ฉันเข้าใจ สิ่งที่ QA ไม่ชอบมากที่สุดคือจะทำงานในตอนเช้า ทำการทดสอบการถดถอยอย่างต่อเนื่อง เหยียบจุดบกพร่องแบบเดียวกับที่พวกเขารายงานไปยังนักพัฒนาเมื่อ 3 sprints ที่แล้วและพูดว่า: “เมื่อไหร่คุณจะ เมอซิเออร์ ดี 'อาร์ตาญ็อง แก้ไขข้อบกพร่องนี้' และ Monsieur D'Artagnan ตอบเขาว่า: "ใช่ใช่ใช่ฉันได้แก้ไขมันแล้ว" และมันเกิดขึ้นได้อย่างไรที่ฉันแก้ไขข้อบกพร่องหนึ่งข้อและทำ 5 ข้อในระหว่างทาง
ผู้ที่สนับสนุนโซลูชันนี้ในการใช้งานจริงต้องการให้โซลูชันนี้ทำงานโดยไม่มีจุดบกพร่อง เพื่อที่พวกเขาจะได้ไม่ต้องรีบูตเซิร์ฟเวอร์ทุกวันศุกร์ ซึ่งเป็นเวลาที่คนทั่วไปไปที่บาร์ นักพัฒนาปรับใช้ในวันศุกร์ ผู้ดูแลระบบนั่งจนถึงวันเสาร์เพื่อพยายามทำให้การปรับใช้นี้เกิดขึ้นและแก้ไข
และเมื่อคุณอธิบายให้คนอื่นทราบว่าพวกเขามีจุดมุ่งหมายเพื่อแก้ไขปัญหาเดียวกัน คุณสามารถดำเนินการตามกระบวนการอย่างเป็นทางการได้ มันสำคัญมาก. ทำไม เพราะเมื่อเราพูดว่า "การทำให้เป็นทางการ" สิ่งสำคัญคือคุณต้องอธิบายว่ากระบวนการของคุณเกิดขึ้นที่ใดที่หนึ่งบนผ้าเช็ดปากเป็นอย่างน้อย คุณต้องเข้าใจว่า ตัวอย่างเช่น หากคุณปรับใช้กับสภาพแวดล้อม QA หรือสภาพแวดล้อมการใช้งานจริง สิ่งนี้จะเกิดขึ้นตามลำดับนี้เสมอ ในขั้นตอนเหล่านี้ เราดำเนินการ เช่น การทดสอบหน่วยอัตโนมัติและการทดสอบ UI หลังจากการปรับใช้ เราจะตรวจสอบว่าการปรับใช้งานเป็นไปด้วยดีหรือไม่ดี แต่คุณมีรายการการดำเนินการที่ชัดเจนที่ต้องทำซ้ำแล้วซ้ำอีกเมื่อคุณปรับใช้กับการใช้งานจริง
และเฉพาะเมื่อกระบวนการของคุณเป็นทางการเท่านั้น คุณจึงเริ่มเลือกผลิตภัณฑ์ที่จะช่วยให้คุณทำให้กระบวนการเหล่านี้เป็นแบบอัตโนมัติได้
น่าเสียดายที่ฉันมักจะเห็นสิ่งนี้เกิดขึ้นในทางกลับกัน ทันทีที่มีคนได้ยินคำว่า “DevOps” พวกเขาก็แนะนำให้ติดตั้ง Jenkins ทันที เพราะพวกเขาเชื่อว่าทันทีที่พวกเขาติดตั้ง Jenkins พวกเขาจะมี DevOps พวกเขาติดตั้ง Jenkins อ่านบทความ “How to” บนเว็บไซต์ Jenkins พยายามรวมกระบวนการต่างๆ ลงในบทความ How to เหล่านี้ จากนั้นจึงไปหาผู้คนและโน้มน้าวผู้คนโดยบอกว่าหนังสือเล่มนี้บอกว่าคุณต้องทำเช่นนี้ ดังนั้นเราจึงทำเช่นนี้
ไม่ใช่ว่าเจนกินส์เป็นเครื่องมือที่ไม่ดี ฉันไม่ได้ตั้งใจจะพูดแบบนั้นแต่อย่างใด แต่นี่เป็นเพียงหนึ่งในผลิตภัณฑ์ และผลิตภัณฑ์ที่คุณใช้ควรเป็นการตัดสินใจครั้งสุดท้ายของคุณ และไม่ใช่สิ่งแรกของคุณ ผลิตภัณฑ์ของคุณไม่ควรขับเคลื่อนด้วยการนำวัฒนธรรมและแนวทางไปใช้ นี่เป็นสิ่งสำคัญมากที่ต้องทำความเข้าใจ ซึ่งเป็นเหตุผลว่าทำไมฉันจึงใช้เวลามากมายกับสไลด์นี้และอธิบายทั้งหมดนี้เป็นเวลานาน
เรามาพูดถึงแนวทางปฏิบัติโดยทั่วไปของ DevOps กันดีกว่า พวกเขาคืออะไร? อะไรคือความแตกต่าง? จะลองสวมได้อย่างไร? ทำไมพวกเขาถึงสำคัญ?
แนวทางปฏิบัติแรกที่คุณอาจเคยได้ยินเรียกว่าการบูรณาการอย่างต่อเนื่อง บางทีบางคนในโครงการอาจมีการบูรณาการอย่างต่อเนื่อง (CI)
ปัญหาที่ใหญ่ที่สุดคือบ่อยครั้งที่สุดเมื่อฉันถามบุคคลว่า “คุณมี CI ในโครงการนี้หรือไม่” และเขาพูดว่า: "ใช่" จากนั้นเมื่อฉันถามว่าเขาทำอะไร เขาจะอธิบายกระบวนการอัตโนมัติทั้งหมดให้ฉันฟังอย่างแน่นอน สิ่งนี้ไม่เป็นความจริงทั้งหมด
ที่จริงแล้ว แนวทางปฏิบัติของ CI มุ่งเป้าไปที่การรวมโค้ดที่คนอื่นเขียนไว้ในฐานโค้ดเดี่ยวบางประเภทเท่านั้น นั่นคือทั้งหมดที่
นอกจาก CI แล้ว ยังมีแนวทางปฏิบัติอื่นๆ ไปด้วย เช่น การปรับใช้อย่างต่อเนื่อง การจัดการการเผยแพร่ แต่เราจะพูดถึงเรื่องนั้นในภายหลัง
CI เองบอกเราว่ามีคนเขียนโค้ดต่างกัน และโค้ดนี้จะต้องรวมเข้ากับโค้ดฐานเดียวอย่างต่อเนื่อง
สิ่งนี้ให้อะไรเราและเหตุใดจึงสำคัญ? ถ้าเรามี DotNet ก็ดี เป็นภาษาที่คอมไพล์ เราก็สามารถคอมไพล์แอปพลิเคชันของเราได้ หากคอมไพล์แล้วนี่ก็เป็นสัญญาณที่ดีอยู่แล้ว นี่ไม่ได้มีความหมายอะไรเลย แต่มันเป็นสัญญาณที่ดีอย่างแรกที่เราสามารถรวบรวมได้
จากนั้นเราจึงทำการทดสอบบางอย่างได้ ซึ่งเป็นแนวทางปฏิบัติที่แยกจากกัน การทดสอบเป็นสีเขียวทั้งหมด – นี่เป็นสัญญาณที่ดีประการที่สอง แต่อีกครั้งนี้ไม่ได้มีความหมายอะไร
แต่ทำไมคุณถึงทำเช่นนี้? แนวทางปฏิบัติทั้งหมดที่ผมจะพูดถึงในวันนี้มีค่าประมาณเดียวกัน กล่าวคือ ผลประโยชน์ที่เหมือนกันโดยประมาณ และวัดผลในลักษณะเดียวกันโดยประมาณด้วย
ประการแรก ช่วยให้คุณสามารถเร่งการจัดส่งได้ สิ่งนี้ช่วยให้คุณเร่งการจัดส่งได้อย่างไร? เมื่อเราทำการเปลี่ยนแปลงใหม่กับฐานโค้ดของเรา เราสามารถลองทำอะไรบางอย่างกับโค้ดนี้ได้ทันที เราไม่รอจนถึงวันพฤหัสบดีเพราะในวันพฤหัสบดีเราจะเผยแพร่ให้กับ QA Environment เราทำตรงนี้และที่นี่
ฉันจะเล่าเรื่องเศร้าหนึ่งเรื่องจากชีวิตของฉันให้คุณฟัง นานมาแล้วตอนที่ฉันยังเด็กและหล่อเหลา ตอนนี้ฉันยังเด็ก สวย ฉลาด และถ่อมตัวอยู่แล้ว เมื่อก่อนฉันอยู่ในโครงการ เรามีทีมงานขนาดใหญ่ที่มีนักพัฒนาประมาณ 30 คน และเรามีโครงการ Enterprise ขนาดใหญ่ที่พัฒนามาประมาณ 10 ปี และเรามีสาขาที่แตกต่างกัน ในพื้นที่เก็บข้อมูลเรามีสาขาที่นักพัฒนาดำเนินการ และมีสาขาที่แสดงเวอร์ชั่นของโค้ดที่ใช้งานจริง
สาขาการผลิตช้ากว่าสาขาที่นักพัฒนาใช้งานได้ 3 เดือน สิ่งนี้หมายความว่า? ซึ่งหมายความว่าทันทีที่ฉันมีข้อบกพร่องที่ไหนสักแห่งที่ไปสู่การผลิตเนื่องจากความผิดของนักพัฒนา เพราะพวกเขาอนุญาต และเนื่องจากความผิดของ QA เพราะพวกเขาตรวจสอบแล้ว นั่นหมายความว่าหากฉันได้รับ งานสำหรับโปรแกรมแก้ไขด่วนสำหรับการผลิต ฉันต้องย้อนกลับการเปลี่ยนแปลงโค้ดเมื่อ 3 เดือนที่แล้ว ฉันต้องจำสิ่งที่ฉันมีเมื่อ 3 เดือนที่แล้วและพยายามแก้ไขที่นั่น
หากคุณยังไม่เคยมีประสบการณ์นี้ คุณสามารถลองใช้ในโครงการบ้านของคุณได้ สิ่งสำคัญคืออย่าลองใช้ในเชิงพาณิชย์ เขียนโค้ดสองสามบรรทัด ลืมมันไปเป็นเวลาหกเดือน จากนั้นกลับมาและพยายามอธิบายอย่างรวดเร็วว่าบรรทัดเหล่านั้นเกี่ยวกับอะไร และคุณจะแก้ไขหรือเพิ่มประสิทธิภาพได้อย่างไร มันเป็นประสบการณ์ที่น่าตื่นเต้นมาก
หากเรามีแนวทางปฏิบัติในการบูรณาการอย่างต่อเนื่อง สิ่งนี้ช่วยให้เราสามารถตรวจสอบด้วยเครื่องมืออัตโนมัติจำนวนหนึ่งได้ที่นี่และในขณะนี้ ทันทีที่ฉันเขียนโค้ด นี่อาจไม่ให้ภาพรวมทั้งหมดแก่ฉัน แต่อย่างไรก็ตาม จะช่วยขจัดความเสี่ยงบางส่วนได้เป็นอย่างน้อย และหากมีข้อบกพร่องใด ๆ ที่อาจเกิดขึ้น ฉันจะทราบทันที นั่นคือภายในไม่กี่นาที ฉันไม่จำเป็นต้องย้อนกลับไป 3 เดือน ฉันจะต้องย้อนกลับไป 2 นาทีเท่านั้น เครื่องชงกาแฟที่ดีจะไม่มีเวลาชงกาแฟภายใน 2 นาทีด้วยซ้ำ ถือว่าเยี่ยมมาก
ซึ่งมีค่าที่สามารถทำซ้ำได้ครั้งแล้วครั้งเล่าในแต่ละโครงการ เช่น ไม่ใช่แค่อันที่คุณตั้งค่าไว้ คุณสามารถทำซ้ำได้ทั้งแบบฝึกหัดและ CI เองก็จะถูกทำซ้ำสำหรับการเปลี่ยนแปลงใหม่ทุกครั้งที่คุณทำกับโปรเจ็กต์ สิ่งนี้ช่วยให้คุณเพิ่มประสิทธิภาพทรัพยากรได้เนื่องจากทีมของคุณทำงานได้อย่างมีประสิทธิภาพมากขึ้น คุณจะไม่มีสถานการณ์ที่ข้อบกพร่องมาถึงคุณจากโค้ดที่คุณใช้งานเมื่อ 3 เดือนที่แล้วอีกต่อไป คุณจะไม่ต้องสลับบริบทอีกต่อไปเมื่อคุณนั่งและใช้เวลาสองชั่วโมงแรกพยายามทำความเข้าใจกับสิ่งที่เกิดขึ้นในขณะนั้น และทำความเข้าใจแก่นแท้ของบริบทก่อนที่คุณจะเริ่มแก้ไขบางสิ่ง
เราจะวัดความสำเร็จหรือความล้มเหลวของการปฏิบัตินี้ได้อย่างไร? หากคุณรายงานต่อหัวหน้าใหญ่ถึงสิ่งที่เราดำเนินการในโครงการ CI เขาจะได้ยินบลา บลา บลา เราปรับใช้มัน โอเค แต่ทำไม มันให้อะไรกับเรา เราจะวัดมันได้อย่างไร เราใช้มันอย่างถูกต้องหรือไม่ถูกต้องแค่ไหน?
ประการแรกคือ ต้องขอบคุณ CI ที่ทำให้เราสามารถปรับใช้ได้บ่อยขึ้น และแม่นยำยิ่งขึ้น เนื่องจากโค้ดของเรามีความเสถียรมากกว่า ในทำนองเดียวกัน เวลาของเราในการค้นหาข้อผิดพลาดก็ลดลง และเวลาในการแก้ไขข้อผิดพลาดก็ลดลงอย่างแม่นยำด้วยเหตุผลที่เราได้รับคำตอบจากระบบที่นี่และขณะนี้ เกิดอะไรขึ้นกับรหัสของเรา
แนวปฏิบัติอีกอย่างหนึ่งที่เรามีคือแนวปฏิบัติการทดสอบระบบอัตโนมัติ ซึ่งส่วนใหญ่มักจะมาพร้อมกับแนวปฏิบัติ CI พวกเขาจับมือกัน
สิ่งสำคัญที่ต้องเข้าใจที่นี่คืออะไร? สิ่งสำคัญคือต้องเข้าใจว่าการทดสอบของเราแตกต่าง และการทดสอบอัตโนมัติแต่ละครั้งมีวัตถุประสงค์เพื่อแก้ไขปัญหาของตัวเอง เรามี Unit Tests ที่ช่วยให้เราสามารถทดสอบโมดูลแยกกันได้ เช่น มันทำงานอย่างไรในสุญญากาศ? ดีจัง.
นอกจากนี้เรายังมีการทดสอบบูรณาการที่ช่วยให้เราเข้าใจว่าโมดูลต่างๆ รวมเข้าด้วยกันอย่างไร มันยังดีอีกด้วย
เราอาจมีการทดสอบการทำงานอัตโนมัติของ UI ที่ช่วยให้เราสามารถตรวจสอบว่าการทำงานกับ UI ตรงตามข้อกำหนดบางประการที่ลูกค้ากำหนดได้ดีเพียงใด เป็นต้น
การทดสอบเฉพาะที่คุณดำเนินการอาจส่งผลต่อความถี่ในการเรียกใช้การทดสอบเหล่านั้น การทดสอบหน่วยมักจะเขียนสั้นและเล็ก และสามารถเปิดตัวได้อย่างสม่ำเสมอ
หากเรากำลังพูดถึงการทดสอบการทำงานอัตโนมัติของ UI คงจะดีถ้าโปรเจ็กต์ของคุณมีขนาดเล็ก การทดสอบการทำงานอัตโนมัติของ UI อาจใช้เวลาพอสมควร แต่โดยปกติแล้วการทดสอบ UI อัตโนมัติเป็นสิ่งที่ต้องใช้เวลาหลายชั่วโมงในโครงการขนาดใหญ่ และจะดีถ้าเป็นเวลาไม่กี่ชั่วโมง สิ่งเดียวก็คือไม่มีประโยชน์ที่จะรันมันในทุกบิลด์ มันสมเหตุสมผลแล้วที่จะวิ่งตอนกลางคืน และเมื่อทุกคนมาทำงานในตอนเช้า ทั้งผู้ทดสอบและนักพัฒนา พวกเขาได้รับรายงานบางประเภทว่าเราทำการทดสอบ UI อัตโนมัติในเวลากลางคืนและได้ผลลัพธ์เหล่านี้ และที่นี่ ชั่วโมงการทำงานของเซิร์ฟเวอร์ที่จะตรวจสอบว่าผลิตภัณฑ์ของคุณตรงตามข้อกำหนดบางประการจะมีราคาถูกกว่าการทำงานหนึ่งชั่วโมงของวิศวกร QA คนเดียวกัน แม้ว่าเขาจะเป็นวิศวกร QA รุ่นเยาว์ที่ทำงานด้านอาหารและขอขอบคุณก็ตาม ในทำนองเดียวกันการทำงานของเครื่องจักรหนึ่งชั่วโมงจะถูกกว่า ด้วยเหตุนี้จึงสมเหตุสมผลที่จะลงทุนในเรื่องนี้
ฉันมีอีกโครงการหนึ่งที่ฉันกำลังทำอยู่ เรามีการวิ่งระยะสั้นสองสัปดาห์สำหรับโปรเจ็กต์นี้ โครงการมีขนาดใหญ่ สำคัญต่อภาคการเงิน ผิดพลาดไม่ได้ และหลังจากการวิ่งสองสัปดาห์ วงจรการพัฒนาก็ตามมาด้วยกระบวนการทดสอบ ซึ่งใช้เวลาอีก 4 สัปดาห์ ลองจินตนาการถึงขนาดของโศกนาฏกรรม เราเขียนโค้ดเป็นเวลาสองสัปดาห์ จากนั้นเราทำแบบเดียวกับ CodeFreeze บรรจุลงในแอปพลิเคชันเวอร์ชันใหม่ และเผยแพร่ให้กับผู้ทดสอบ ผู้ทดสอบจะทดสอบอีก 4 สัปดาห์เช่น ขณะที่พวกเขากำลังทดสอบ เราก็มีเวลาเตรียมอีกสองเวอร์ชันให้พวกเขา นี่เป็นกรณีที่น่าเศร้าจริงๆ
และเราบอกพวกเขาว่าหากคุณต้องการมีประสิทธิผลมากขึ้น คุณควรนำแนวทางปฏิบัติในการทดสอบอัตโนมัติไปใช้ เพราะนี่คือสิ่งที่ทำให้คุณเจ็บปวดตรงนี้ในเวลานี้
ฝึกปฏิบัติการใช้งานอย่างต่อเนื่อง เยี่ยมมาก คุณสร้างเสร็จแล้ว นี่ก็ดีอยู่แล้ว รหัสของคุณได้ถูกรวบรวมแล้ว ตอนนี้ คงจะดีไม่น้อยหากปรับใช้บิวด์นี้ในบางสภาพแวดล้อม สมมติว่าในสภาพแวดล้อมสำหรับนักพัฒนา
ทำไมมันถึงสำคัญ? ขั้นแรก คุณสามารถดูได้ว่ากระบวนการปรับใช้ของคุณประสบความสำเร็จเพียงใด ฉันเคยเจอโปรเจ็กต์แบบนี้เมื่อฉันถามว่า "คุณจะปรับใช้แอปพลิเคชันเวอร์ชันใหม่ได้อย่างไร" พวกเขาบอกฉัน: "เรารวบรวมมันและแพ็คมันลงในไฟล์ zip เราส่งให้ผู้ดูแลระบบทางไปรษณีย์ ผู้ดูแลระบบดาวน์โหลดและขยายไฟล์เก็บถาวรนี้ และทั้งสำนักงานก็เริ่มอธิษฐานขอให้เซิร์ฟเวอร์รับเวอร์ชันใหม่”
เริ่มจากสิ่งง่ายๆ ตัวอย่างเช่น พวกเขาลืมใส่ CSS ในไฟล์เก็บถาวร หรือลืมเปลี่ยนแฮชแท็กในชื่อไฟล์ java-script และเมื่อเราส่งคำขอไปยังเซิร์ฟเวอร์ เบราว์เซอร์จะคิดว่ามีไฟล์จาวาสคริปต์นี้อยู่แล้ว และตัดสินใจว่าจะไม่ดาวน์โหลด และมีรุ่นเก่ามีบางอย่างขาดหายไป โดยทั่วไปอาจมีปัญหามากมาย ดังนั้น แนวทางปฏิบัติของการปรับใช้งานอย่างต่อเนื่องทำให้อย่างน้อยคุณสามารถทดสอบว่าจะเกิดอะไรขึ้นหากคุณใช้อิมเมจอ้างอิงที่ชัดเจนและอัปโหลดไปยังสภาพแวดล้อมใหม่ที่สะอาดหมดจด คุณสามารถดูได้ว่าสิ่งนี้นำไปสู่จุดใด
นอกจากนี้ เมื่อคุณรวมโค้ดระหว่างกัน เช่น ระหว่างคำสั่งนี้จะทำให้คุณเห็นว่ามันดูเป็นอย่างไรบน UI
ปัญหาหนึ่งที่เกิดขึ้นเมื่อมีการใช้ vanilla java-script จำนวนมากคือนักพัฒนาสองคนได้ประกาศตัวแปรที่มีชื่อเดียวกันในวัตถุหน้าต่างโดยไม่ได้ตั้งใจ แล้วขึ้นอยู่กับโชคของคุณ ไฟล์จาวาสคริปต์ที่ถูกดึงออกมาเป็นอันดับสองจะเขียนทับการเปลี่ยนแปลงของไฟล์อื่น มันยังน่าตื่นเต้นมาก คุณเข้ามา: สิ่งหนึ่งที่ได้ผลสำหรับคนคนหนึ่ง อีกอย่างหนึ่งใช้ไม่ได้กับอีกคนหนึ่ง และมัน “มหัศจรรย์” เมื่อทุกอย่างถูกผลิตออกมา
แนวปฏิบัติต่อไปที่เรามีคือแนวปฏิบัติของ Automatic Restore ซึ่งก็คือการย้อนกลับไปเป็นเวอร์ชันก่อนหน้าของแอปพลิเคชัน
เหตุใดสิ่งนี้จึงสำคัญสำหรับนักพัฒนา? ยังมีคนที่จำยุค 90 อันห่างไกลเมื่อคอมพิวเตอร์มีขนาดใหญ่และโปรแกรมมีขนาดเล็ก และวิธีเดียวในการพัฒนาเว็บไซต์คือผ่าน PHP ไม่ใช่ว่า PHP เป็นภาษาที่ไม่ดีถึงแม้ว่ามันจะเป็นเช่นนั้นก็ตาม
แต่ปัญหาก็แตกต่างออกไป เมื่อเราปรับใช้ไซต์ php เวอร์ชันใหม่ เราจะปรับใช้อย่างไร ส่วนใหญ่เราเปิด Far Manager หรืออย่างอื่น และอัพโหลดไฟล์เหล่านี้ไปยัง FTP และทันใดนั้นเราก็ตระหนักได้ว่าเรามีจุดบกพร่องเล็กๆ น้อยๆ เช่น เราลืมใส่เครื่องหมายอัฒภาคหรือลืมเปลี่ยนรหัสผ่านสำหรับฐานข้อมูล และมีรหัสผ่านสำหรับฐานข้อมูลซึ่งอยู่บนโฮสต์ภายในเครื่อง และเราตัดสินใจที่จะเชื่อมต่อกับ FTP อย่างรวดเร็วและแก้ไขไฟล์ตรงนั้น นี่แค่ไฟ! นี่คือสิ่งที่ได้รับความนิยมในยุค 90
แต่ถ้าคุณไม่ดูปฏิทิน ยุค 90 ก็เกือบ 30 ปีที่แล้ว ตอนนี้ทุกอย่างเกิดขึ้นแตกต่างออกไปเล็กน้อย และลองจินตนาการถึงขนาดของโศกนาฏกรรมเมื่อพวกเขาบอกคุณว่า: “เราได้นำไปใช้งานแล้ว แต่มีบางอย่างผิดพลาดเกิดขึ้น นี่คือข้อมูลเข้าสู่ระบบ FTP และรหัสผ่านของคุณ เชื่อมต่อกับการใช้งานจริงและแก้ไขอย่างรวดเร็วที่นั่น” ถ้าคุณเป็นชัค นอร์ริส สิ่งนี้ก็จะได้ผล ถ้าไม่เช่นนั้น คุณเสี่ยงว่าหากคุณแก้ไขข้อบกพร่องหนึ่งข้อ คุณจะทำเพิ่มอีก 10 จุด นี่คือเหตุผลว่าทำไมการย้อนกลับไปใช้เวอร์ชันก่อนหน้าจึงทำให้คุณประสบความสำเร็จได้มาก
แม้ว่าจะมีสิ่งเลวร้ายเกิดขึ้นที่ไหนสักแห่ง แต่มันก็แย่ แต่ก็ไม่ถึงแก่ชีวิต คุณสามารถย้อนกลับไปเป็นเวอร์ชันก่อนหน้าที่คุณมีได้ เรียกมันว่าการสำรองข้อมูลถ้ามันง่ายกว่าที่จะรับรู้ในคำศัพท์นั้น คุณสามารถย้อนกลับเป็นเวอร์ชันก่อนหน้าได้ และผู้ใช้จะยังสามารถทำงานกับผลิตภัณฑ์ของคุณได้ และคุณจะมีเวลาบัฟเฟอร์เพียงพอ คุณสามารถดำเนินการทั้งหมดนี้อย่างใจเย็น โดยไม่ต้องรีบร้อน และทดสอบในเครื่อง แก้ไข แล้วอัปโหลดเวอร์ชันใหม่ มันสมเหตุสมผลจริงๆที่จะทำเช่นนี้
ทีนี้ลองรวมวิธีปฏิบัติสองข้อก่อนหน้านี้เข้าด้วยกัน เราจะได้อันที่สามที่เรียกว่า Release Management
เมื่อเราพูดถึง Continuous Deployment ในรูปแบบคลาสสิก เราบอกว่าเราต้องดึงโค้ดจากบางสาขาจาก repository คอมไพล์และปรับใช้มัน คงจะดีถ้าเรามีสภาพแวดล้อมที่เหมือนกัน หากเรามีสภาพแวดล้อมหลายแบบ นั่นหมายความว่าเราต้องดึงโค้ดทุกครั้ง แม้ว่าจะมาจากการคอมมิตเดียวกันก็ตาม เราจะดึงมันออกมาทุกครั้ง เราจะสร้างมันขึ้นมาทุกครั้ง และเราจะปรับใช้มันกับสภาพแวดล้อมใหม่ ก่อนอื่น นี่คือเวลา เพราะในการสร้างโปรเจ็กต์ หากคุณมีโครงการขนาดใหญ่และมาจากยุค 90 อาจต้องใช้เวลาหลายชั่วโมง
แถมยังมีเรื่องเศร้าอีก เมื่อคุณสร้าง แม้จะอยู่บนเครื่องเดียวกัน คุณจะสร้างแหล่งที่มาเดียวกัน คุณยังคงไม่มีการรับประกันว่าเครื่องนี้จะอยู่ในสถานะเดียวกับที่อยู่ระหว่างการสร้างครั้งล่าสุด
สมมติว่ามีคนเข้ามาและอัปเดต DotNet ให้คุณ หรือในทางกลับกัน มีคนตัดสินใจลบบางสิ่ง แล้วคุณมีความไม่ลงรอยกันทางการรับรู้ว่าจากการกระทำนี้เมื่อสองสัปดาห์ก่อนเรากำลังสร้างงานสร้างและทุกอย่างเรียบร้อยดี แต่ตอนนี้ดูเหมือนว่าเป็นเครื่องจักรเดียวกัน การคอมมิตเดียวกัน รหัสเดียวกับที่เราพยายามสร้าง แต่มันไม่ทำงาน . คุณจะต้องรับมือกับเรื่องนี้เป็นเวลานานและไม่ใช่ความจริงที่ว่าคุณจะเข้าใจเรื่องนี้ อย่างน้อยที่สุด คุณก็จะเสียประสาทได้มาก
ดังนั้นแนวทางปฏิบัติในการจัดการการเผยแพร่แนะนำให้แนะนำนามธรรมเพิ่มเติมที่เรียกว่าที่เก็บวัตถุหรือแกลเลอรีหรือไลบรารี คุณสามารถเรียกมันว่าสิ่งที่คุณต้องการ
แนวคิดหลักคือทันทีที่เรามี Commit บางอย่าง เช่น ในสาขาที่เราพร้อมที่จะปรับใช้กับสภาพแวดล้อมที่แตกต่างกันของเรา เราจะรวบรวมแอปพลิเคชันจาก Commit นี้และทุกสิ่งที่เราต้องการสำหรับแอปพลิเคชันนี้ เราก็แพ็คมัน ลงในไฟล์ zip และบันทึกไว้ในที่เก็บข้อมูลที่เชื่อถือได้ และจากที่เก็บข้อมูลนี้เราสามารถรับไฟล์ zip นี้ได้ตลอดเวลา
จากนั้นเราจะนำไปปรับใช้กับสภาพแวดล้อม dev โดยอัตโนมัติ เราลงแข่งที่นั่น และถ้าทุกอย่างดี เราก็จะขึ้นเวที หากทุกอย่างเป็นไปด้วยดี เราจะปรับใช้ไฟล์เก็บถาวรเดียวกันเพื่อการใช้งานจริง ซึ่งเป็นไบนารีเดียวกันที่คอมไพล์เพียงครั้งเดียว
นอกจากนี้ เมื่อเรามีแกลเลอรีเช่นนี้ ยังช่วยให้เราจัดการกับความเสี่ยงที่เราระบุไว้ในสไลด์ที่แล้วเมื่อเราพูดถึงการย้อนกลับไปยังเวอร์ชันก่อนหน้า หากคุณปรับใช้สิ่งผิดปกติโดยไม่ตั้งใจ คุณสามารถนำเวอร์ชันก่อนหน้าอื่นๆ จากแกลเลอรีนี้และยกเลิกการปรับใช้กับสภาพแวดล้อมเหล่านี้ในลักษณะเดียวกันได้ตลอดเวลา ซึ่งจะทำให้คุณสามารถย้อนกลับไปยังเวอร์ชันก่อนหน้าได้อย่างง่ายดายหากมีสิ่งผิดปกติเกิดขึ้น
มีการปฏิบัติที่ดีอีกประการหนึ่ง คุณและฉันต่างเข้าใจว่าเมื่อเราย้อนกลับแอปพลิเคชันของเราไปเป็นเวอร์ชันก่อนหน้า นี่อาจหมายความว่าเราจำเป็นต้องมีโครงสร้างพื้นฐานของเวอร์ชันก่อนหน้าด้วย
เมื่อเราพูดถึงโครงสร้างพื้นฐานเสมือน หลายคนคิดว่านี่คือสิ่งที่ผู้ดูแลระบบตั้งค่าไว้ และหากคุณต้องการเซิร์ฟเวอร์ใหม่ที่คุณต้องการทดสอบแอปพลิเคชันเวอร์ชันใหม่ คุณจะต้องเขียนตั๋วถึงผู้ดูแลระบบหรือ Devops Devops จะใช้เวลา 3 สัปดาห์ในการดำเนินการนี้ และหลังจากผ่านไป 3 สัปดาห์ พวกเขาจะแจ้งให้คุณทราบว่าเราได้ติดตั้งเครื่องเสมือนให้กับคุณ โดยมีหนึ่งคอร์, RAM สองกิกะไบต์ และเซิร์ฟเวอร์ Windows ที่ไม่มี DotNet คุณพูดว่า: "แต่ฉันต้องการ DotNet" พวกเขา: “ตกลง กลับมาอีกครั้งใน 3 สัปดาห์”
แนวคิดก็คือการใช้โครงสร้างพื้นฐานเป็นแนวปฏิบัติด้านโค้ด คุณสามารถถือว่าโครงสร้างพื้นฐานเสมือนของคุณเป็นเพียงทรัพยากรอื่นได้
บางที ถ้าใครกำลังพัฒนาแอปพลิเคชันบน DotNet คุณอาจเคยได้ยินเกี่ยวกับไลบรารีชื่อ Entity Framework มาก่อน และคุณอาจเคยได้ยินมาว่า Entity Framework เป็นหนึ่งในแนวทางที่ Microsoft กำลังผลักดันอย่างจริงจัง สำหรับการทำงานกับฐานข้อมูล นี่คือแนวทางที่เรียกว่า Code First นี่คือเมื่อคุณอธิบายด้วยโค้ดว่าคุณต้องการให้ฐานข้อมูลของคุณมีลักษณะอย่างไร จากนั้นคุณก็ปรับใช้แอปพลิเคชัน มันเชื่อมต่อกับฐานข้อมูล โดยตัวมันเองจะกำหนดว่าตารางใดที่มีอยู่และตารางใดที่ไม่ใช่ และสร้างทุกสิ่งที่คุณต้องการ
คุณสามารถทำเช่นเดียวกันกับโครงสร้างพื้นฐานของคุณได้ ไม่มีความแตกต่างระหว่างว่าคุณต้องการฐานข้อมูลสำหรับโครงการหรือคุณต้องการเซิร์ฟเวอร์ Windows สำหรับโครงการ มันเป็นเพียงทรัพยากร และคุณสามารถสร้างทรัพยากรนี้ได้โดยอัตโนมัติ คุณสามารถกำหนดค่าทรัพยากรนี้ได้โดยอัตโนมัติ ดังนั้น ทุกครั้งที่คุณต้องการทดสอบแนวคิดใหม่ วิธีการใหม่ คุณไม่จำเป็นต้องเขียนตั๋วเพื่อ Devops คุณสามารถปรับใช้โครงสร้างพื้นฐานแบบแยกสำหรับตัวคุณเองจากเทมเพลตสำเร็จรูป จากสคริปต์สำเร็จรูปและนำไปใช้งาน มีการทดลองทั้งหมดของคุณ คุณสามารถลบสิ่งนี้ รับผลลัพธ์บางส่วน และรายงานเพิ่มเติมเกี่ยวกับเรื่องนี้ได้
แนวปฏิบัติถัดไปซึ่งมีอยู่และมีความสำคัญเช่นกัน แต่มีเพียงไม่กี่คนที่ใช้คือ Application Performance Monitoring
ฉันอยากจะพูดเพียงสิ่งเดียวเกี่ยวกับ Application Performance Monitoring สิ่งที่สำคัญที่สุดเกี่ยวกับการปฏิบัตินี้? นี่คือสิ่งที่ Application Performance Monitoring เหมือนกับการซ่อมแซมอพาร์ทเมนต์ นี่ไม่ใช่สถานะสุดท้าย แต่เป็นกระบวนการ คุณต้องทำอย่างสม่ำเสมอ
ในทางที่ดี การดำเนินการตรวจสอบประสิทธิภาพของแอปพลิเคชันในเกือบทุกรุ่นจะเป็นการดี แม้ว่าอย่างที่คุณเข้าใจแล้ว สิ่งนี้ไม่สามารถทำได้เสมอไป แต่อย่างน้อยที่สุดก็ต้องดำเนินการในแต่ละรุ่น
ทำไมมันถึงสำคัญ? เพราะหากคุณประสบกับประสิทธิภาพที่ลดลงอย่างกะทันหัน คุณจะต้องเข้าใจอย่างชัดเจนว่าทำไม หากทีมของคุณมีระยะเวลาเร่งด่วนสองสัปดาห์ อย่างน้อยหนึ่งครั้งทุกๆ สองสัปดาห์ คุณควรปรับใช้แอปพลิเคชันของคุณกับเซิร์ฟเวอร์ที่แยกจากกัน ซึ่งคุณมีโปรเซสเซอร์ RAM ดิสก์ ฯลฯ ที่คงที่อย่างชัดเจน และทำการทดสอบประสิทธิภาพแบบเดียวกันเหล่านั้น . คุณได้รับผลลัพธ์ ดูว่ามันเปลี่ยนแปลงไปจากการวิ่งครั้งก่อนอย่างไร
และหากคุณพบว่าการเบิกเงินลดลงอย่างรวดเร็วที่ไหนสักแห่ง นั่นหมายความว่าเป็นเพียงเพราะการเปลี่ยนแปลงที่เกิดขึ้นในช่วงสองสัปดาห์ที่ผ่านมา วิธีนี้จะช่วยให้คุณระบุและแก้ไขปัญหาได้เร็วยิ่งขึ้น และขอย้ำอีกครั้งว่านี่เป็นตัวชี้วัดเดียวกันโดยประมาณซึ่งคุณสามารถวัดความสำเร็จของคุณได้
แนวปฏิบัติถัดไปที่เรามีคือแนวปฏิบัติการจัดการการกำหนดค่า มีน้อยมากที่จริงจังกับเรื่องนี้ แต่เชื่อฉันเถอะว่านี่เป็นเรื่องที่จริงจังมากจริงๆ
เมื่อเร็วๆ นี้ มีเรื่องตลกเกิดขึ้น พวกเขามาหาฉันแล้วพูดว่า: “ช่วยเราทำการตรวจสอบความปลอดภัยของใบสมัครของเรา” เราดูโค้ดด้วยกันเป็นเวลานาน พวกเขาบอกฉันเกี่ยวกับแอปพลิเคชัน วาดไดอะแกรม และบวกหรือลบทุกอย่างมีเหตุผล เข้าใจได้ ปลอดภัย แต่มีอย่างหนึ่ง แต่! พวกเขามีไฟล์การกำหนดค่าในการควบคุมแหล่งที่มา รวมถึงไฟล์จากการผลิตด้วยฐานข้อมูล IP พร้อมข้อมูลเข้าสู่ระบบและรหัสผ่านสำหรับการเชื่อมต่อกับฐานข้อมูลเหล่านี้ ฯลฯ
และฉันพูดว่า:“ พวกคุณโอเคคุณได้ปิดสภาพแวดล้อมการผลิตของคุณด้วยไฟร์วอลล์ แต่ความจริงที่ว่าคุณมีข้อมูลเข้าสู่ระบบและรหัสผ่านสำหรับฐานข้อมูลการผลิตในการควบคุมแหล่งที่มาและนักพัฒนาทุกคนสามารถอ่านได้ มันเป็นความเสี่ยงด้านความปลอดภัยอย่างมากอยู่แล้ว . และไม่ว่าแอปพลิเคชันของคุณจะมีความปลอดภัยสูงเพียงใดจากมุมมองของโค้ด หากคุณปล่อยมันไว้ในการควบคุมแหล่งที่มา คุณจะไม่ผ่านการตรวจสอบใดๆ เลย” นั่นคือสิ่งที่ฉันพูดถึง.
การจัดการการตั้งค่า. เราอาจมีการกำหนดค่าที่แตกต่างกันในสภาพแวดล้อมที่แตกต่างกัน ตัวอย่างเช่น เราอาจมีข้อมูลเข้าสู่ระบบและรหัสผ่านที่แตกต่างกันสำหรับฐานข้อมูลสำหรับ QA การสาธิต สภาพแวดล้อมการใช้งานจริง ฯลฯ
การกำหนดค่านี้สามารถเป็นแบบอัตโนมัติได้เช่นกัน ควรแยกจากตัวแอปพลิเคชันเสมอ ทำไม เนื่องจากคุณสร้างแอปพลิเคชันขึ้นมาเพียงครั้งเดียว จากนั้นแอปพลิเคชันจะไม่สนใจว่าคุณจะเชื่อมต่อกับเซิร์ฟเวอร์ SQL ผ่านทาง IP ดังกล่าวหรือดังกล่าว และ IP ดังกล่าว จึงควรทำงานเหมือนเดิม ดังนั้นหากจู่ๆ คุณคนใดคนหนึ่งยังคงฮาร์ดโค้ดสตริงการเชื่อมต่อในโค้ดอยู่ จำไว้ว่าฉันจะตามหาคุณและลงโทษคุณหากคุณพบว่าตัวเองอยู่ในโปรเจ็กต์เดียวกันกับฉัน ซึ่งจะถูกวางไว้ในการกำหนดค่าแยกต่างหากเสมอ เช่น ใน web.config
และการกำหนดค่านี้ได้รับการจัดการแยกกันอยู่แล้ว กล่าวคือ นี่คือช่วงเวลาที่นักพัฒนาและผู้ดูแลระบบสามารถมานั่งในห้องเดียวกันได้ และนักพัฒนาสามารถพูดว่า: “ดูสิ นี่คือไบนารีของแอปพลิเคชันของฉัน งานของเขา. แอปพลิเคชันต้องการฐานข้อมูลในการทำงาน ถัดจากไบนารีจะมีไฟล์อยู่ ในไฟล์นี้ ฟิลด์นี้มีหน้าที่รับผิดชอบในการเข้าสู่ระบบ นี่คือรหัสผ่าน และสำหรับ IP เอาไปวางที่ไหนก็ได้” และเป็นเรื่องง่ายและชัดเจนสำหรับผู้ดูแลระบบ เขาสามารถติดตั้งใช้งานได้ทุกที่ด้วยการจัดการการกำหนดค่านี้
และแบบฝึกหัดสุดท้ายที่ฉันอยากจะพูดถึงคือแบบฝึกหัดที่เกี่ยวข้องกับเมฆอย่างมาก และจะให้ผลสูงสุดหากคุณทำงานบนคลาวด์ นี่คือการลบสภาพแวดล้อมของคุณโดยอัตโนมัติ
ฉันรู้ว่ามีหลายคนในการประชุมครั้งนี้จากทีมที่ฉันทำงานด้วย และกับทุกทีมที่ฉันทำงานด้วย เราใช้แนวทางปฏิบัตินี้
ทำไม แน่นอนว่า คงจะดีไม่น้อยหากนักพัฒนาแต่ละคนมีเครื่องเสมือนที่ทำงานตลอด 24 ชั่วโมงทุกวัน แต่บางทีนี่อาจเป็นข่าวสำหรับคุณ บางทีคุณอาจไม่ได้ใส่ใจ แต่นักพัฒนาเองก็ไม่ได้ทำงานตลอด 7 ชั่วโมงทุกวัน นักพัฒนามักจะทำงาน 24 ชั่วโมงต่อวัน แม้ว่าเขาจะมาทำงานเร็ว แต่เขาก็มีอาหารกลางวันมื้อใหญ่ในระหว่างที่เขาไปออกกำลังกาย ปล่อยให้เป็นเวลา 7 ชั่วโมงต่อวันเมื่อนักพัฒนาใช้ทรัพยากรเหล่านี้จริงๆ ตามกฎหมายของเรา เรามี 8 วันจาก 12 วันในหนึ่งสัปดาห์ซึ่งถือเป็นวันทำงาน
ดังนั้นในวันธรรมดาเครื่องนี้ไม่ควรทำงานตลอด 24 ชั่วโมง แต่เพียง 12 ชั่วโมงเท่านั้น และในวันหยุดสุดสัปดาห์เครื่องนี้ไม่ควรทำงานเลย ดูเหมือนว่าทุกอย่างจะง่ายมาก แต่สิ่งสำคัญที่ต้องพูดที่นี่คืออะไร? การนำแนวปฏิบัติง่ายๆ นี้ไปใช้ในกำหนดการพื้นฐานนี้ จะช่วยให้คุณสามารถลดต้นทุนในการบำรุงรักษาสภาพแวดล้อมเหล่านี้ได้ถึง 70% กล่าวคือ คุณเอาราคาของ dev, QA, การสาธิต, สภาพแวดล้อม แล้วหารด้วย 3
คำถามคือ แล้วเงินที่เหลือจะทำยังไง? ตัวอย่างเช่น นักพัฒนาควรซื้อ ReSharper หากยังไม่ได้ซื้อ หรือมีงานเลี้ยงค็อกเทล หากก่อนหน้านี้คุณมีสภาพแวดล้อมเดียวที่ทั้ง dev และ QA กินหญ้า และเพียงเท่านี้ ตอนนี้คุณสามารถสร้างสภาพแวดล้อมที่แตกต่างกัน 3 แบบที่จะแยกออกจากกัน และผู้คนจะไม่เข้าไปยุ่งเกี่ยวกับกันและกัน
ส่วนสไลด์ที่มีการวัดประสิทธิภาพอย่างต่อเนื่อง เราจะเปรียบเทียบประสิทธิภาพได้อย่างไร ในเมื่อเรามี 1 บันทึกในฐานข้อมูลในโครงการ สองเดือนต่อมามีเป็นล้าน? จะเข้าใจได้อย่างไรว่าทำไมและอะไรคือประเด็นในการวัดประสิทธิภาพ?
นี่เป็นคำถามที่ดี เพราะคุณควรวัดประสิทธิภาพบนทรัพยากรเดียวกันเสมอ นั่นคือ คุณเปิดตัวโค้ดใหม่ คุณวัดประสิทธิภาพของโค้ดใหม่ ตัวอย่างเช่น คุณต้องทดสอบสถานการณ์ประสิทธิภาพที่แตกต่างกัน สมมติว่าคุณต้องการทดสอบว่าแอปพลิเคชันทำงานอย่างไรบนโหลดที่ไม่รุนแรง โดยมีผู้ใช้ 1 รายและขนาดฐานข้อมูลคือ 000 กิกะไบต์ คุณวัดมันแล้วได้ตัวเลข ต่อไปเราจะใช้สถานการณ์อื่น เช่น ผู้ใช้ 5 ราย ฐานข้อมูลขนาด 5 เทราไบต์ เราได้รับผลลัพธ์และจดจำไว้
มีอะไรสำคัญที่นี่? สิ่งสำคัญที่นี่คือขึ้นอยู่กับสถานการณ์ ปริมาณข้อมูล จำนวนผู้ใช้พร้อมกัน ฯลฯ คุณอาจพบขีดจำกัดบางอย่าง ตัวอย่างเช่น จนถึงขีดจำกัดของการ์ดเครือข่าย หรือจนถึงขีดจำกัดของฮาร์ดไดรฟ์ หรือจนถึงขีดจำกัดความสามารถของโปรเซสเซอร์ นี่คือสิ่งสำคัญสำหรับคุณที่จะเข้าใจ ในสถานการณ์ที่แตกต่างกัน คุณจะพบกับขีดจำกัดบางอย่าง และคุณต้องเข้าใจตัวเลขเมื่อคุณตีมัน
เรากำลังพูดถึงการวัดประสิทธิภาพในสภาพแวดล้อมการทดสอบพิเศษหรือไม่? นั่นคือนี่ไม่ใช่การผลิตใช่ไหม
ใช่ นี่ไม่ใช่การใช้งานจริง นี่คือสภาพแวดล้อมการทดสอบ ซึ่งจะเหมือนกันเสมอ เพื่อให้คุณสามารถเปรียบเทียบกับการวัดก่อนหน้านี้ได้
ใช่, спасибо!
หากไม่มีคำถามใด ๆ ฉันคิดว่าเราสามารถจบได้ ขอบคุณ!
ที่มา: will.com