เราพัฒนา DevOps ให้ดีที่สุดเท่าที่เราจะทำได้ พวกเรามีกัน 8 คนและวาสยาเป็นคนที่เจ๋งที่สุดใน Windows ทันใดนั้น Vasya ก็จากไป และฉันมีงานเปิดตัวโครงการใหม่ที่จัดทำโดยการพัฒนา Windows เมื่อฉันทิ้งสแต็กการพัฒนา Windows ทั้งหมดลงบนโต๊ะ ฉันรู้ว่าสถานการณ์นั้นช่างเจ็บปวด...
นี่คือวิธีที่เรื่องราวเริ่มต้นขึ้น อเล็กซานดรา ซินชิโนวา บน . เมื่อผู้เชี่ยวชาญ Windows ชั้นนำออกจากบริษัท Alexander สงสัยว่าจะต้องทำอะไรตอนนี้ เปลี่ยนไปใช้ Linux แน่นอน! Alexander จะบอกคุณว่าเขาจัดการสร้างแบบอย่างและถ่ายโอนส่วนหนึ่งของการพัฒนา Windows ไปยัง Linux ได้อย่างไรโดยใช้ตัวอย่างโครงการที่เสร็จสมบูรณ์สำหรับผู้ใช้ปลายทาง 100 ราย
จะส่งโปรเจ็กต์ไปยัง RPM โดยใช้ TFS, Puppet, Linux .NET core ได้อย่างง่ายดายและง่ายดายได้อย่างไร จะสนับสนุนการกำหนดเวอร์ชันของฐานข้อมูลโครงการได้อย่างไรหากทีมพัฒนาได้ยินคำว่า Postgres และ Flyway เป็นครั้งแรก และกำหนดเวลาคือวันมะรืนนี้ จะทำงานร่วมกับ Docker ได้อย่างไร? จะกระตุ้นให้นักพัฒนา. NET ละทิ้ง Windows และสมูทตี้เพื่อสนับสนุน Puppet และ Linux ได้อย่างไร จะแก้ไขความขัดแย้งทางอุดมการณ์ได้อย่างไรหากไม่มีทั้งความเข้มแข็งหรือความปรารถนาหรือทรัพยากรในการบำรุงรักษา Windows ในการผลิต? เกี่ยวกับเรื่องนี้ รวมถึง Web Deploy, การทดสอบ, CI, เกี่ยวกับแนวทางปฏิบัติในการใช้ TFS ในโปรเจ็กต์ที่มีอยู่ และแน่นอน เกี่ยวกับไม้ค้ำยันที่หักและวิธีแก้ปัญหาการทำงาน ในบันทึกของรายงานของ Alexander
ดังนั้น Vasya จากไป งานเป็นของฉัน นักพัฒนากำลังรอโกยอย่างไม่อดทน ในที่สุดเมื่อฉันรู้ว่าวาสยาไม่สามารถกลับมาได้ ฉันก็ลงมือทำธุรกิจ อันดับแรก ฉันประเมินเปอร์เซ็นต์ของ Win VM ในฟลีตของเรา คะแนนไม่เข้าข้าง Windows
เนื่องจากเรากำลังพัฒนา DevOps อย่างแข็งขัน ฉันจึงตระหนักว่าต้องมีบางสิ่งที่จำเป็นต้องเปลี่ยนแปลงในแนวทางการส่งมอบแอปพลิเคชันใหม่ มีเพียงวิธีเดียวเท่านั้น - หากเป็นไปได้ ให้ถ่ายโอนทุกอย่างไปยัง Linux Google ช่วยฉัน - ในเวลานั้น .Net ได้รับการย้ายไปยัง Linux แล้ว และฉันก็รู้ว่านี่คือวิธีแก้ปัญหา!
ทำไม. NET core ร่วมกับ Linux?
มีสาเหตุหลายประการสำหรับเรื่องนี้ ระหว่าง “จ่ายเงิน” กับ “ไม่จ่าย” ส่วนใหญ่จะเลือกอย่างที่สองเหมือนฉัน ใบอนุญาตสำหรับ MSDB มีราคาประมาณ 1 ดอลลาร์ ส่วนการบำรุงรักษาเครื่องเสมือน Windows มีค่าใช้จ่ายหลายร้อยดอลลาร์ สำหรับบริษัทขนาดใหญ่ นี่เป็นค่าใช้จ่ายก้อนใหญ่ นั่นเป็นเหตุผล เงินออม - เหตุผลแรก. ไม่ใช่สิ่งที่สำคัญที่สุด แต่เป็นหนึ่งในสิ่งที่สำคัญที่สุด
เครื่องเสมือน Windows ใช้ทรัพยากรมากกว่าพี่น้อง Linux - พวกเขาหนัก. เมื่อพิจารณาถึงขนาดของบริษัทขนาดใหญ่ เราจึงเลือก Linux
ระบบถูกรวมเข้ากับ CI ที่มีอยู่อย่างง่ายดาย. เราถือว่า DevOps มีความก้าวหน้า เราใช้ Bamboo, Jenkins และ GitLab CI ดังนั้นงานส่วนใหญ่ของเราจึงทำงานบน Linux
เหตุผลสุดท้ายก็คือ คลอสะดวก เราจำเป็นต้องลดอุปสรรคในการเข้าสำหรับ "เพื่อนเที่ยว"—ผู้ที่เข้าใจส่วนทางเทคนิค รับรองการบริการที่ไม่หยุดชะงัก และรักษาบริการจากบรรทัดที่สอง พวกเขาคุ้นเคยกับ Linux Stack อยู่แล้ว ดังนั้นจึงง่ายกว่ามากสำหรับพวกเขาที่จะเข้าใจ สนับสนุน และดูแลรักษาผลิตภัณฑ์ใหม่ มากกว่าการใช้ทรัพยากรเพิ่มเติมเพื่อทำความเข้าใจฟังก์ชันการทำงานแบบเดียวกันของซอฟต์แวร์สำหรับแพลตฟอร์ม Windows
ความต้องการ
ก่อนอื่น - ความสะดวกสบายของโซลูชั่นใหม่สำหรับนักพัฒนา. ไม่ใช่ทุกคนที่จะพร้อมสำหรับการเปลี่ยนแปลง โดยเฉพาะอย่างยิ่งหลังจากที่มีการพูดคำว่า Linux นักพัฒนาต้องการ Visual Studio, TFS ที่พวกเขาชื่นชอบพร้อมการทดสอบอัตโนมัติสำหรับแอสเซมบลีและสมูทตี้ การส่งมอบไปสู่การผลิตนั้นไม่สำคัญสำหรับพวกเขา ดังนั้นเราจึงตัดสินใจที่จะไม่เปลี่ยนกระบวนการปกติและปล่อยให้ทุกอย่างไม่เปลี่ยนแปลงสำหรับการพัฒนา Windows
จำเป็นต้องมีโครงการใหม่ รวมเข้ากับ CI ที่มีอยู่. รางอยู่ที่นั่นแล้ว และงานทั้งหมดต้องคำนึงถึงพารามิเตอร์ของระบบการจัดการการกำหนดค่า มาตรฐานการส่งมอบที่ยอมรับ และระบบการตรวจสอบ
ง่ายต่อการสนับสนุนและการดำเนินงานเป็นเงื่อนไขสำหรับเกณฑ์ขั้นต่ำสำหรับผู้เข้าร่วมใหม่ทั้งหมดจากแผนกต่างๆ และแผนกสนับสนุน
กำหนดเวลา - เมื่อวาน.
วิน ดีเวลลอปเมนท์ กรุ๊ป
ตอนนั้นทีม Windows ทำงานร่วมกับอะไร?
ตอนนี้ฉันสามารถพูดได้อย่างมั่นใจ IdentityServer4 เป็นทางเลือกฟรีที่ยอดเยี่ยมสำหรับ ADFS ที่มีความสามารถคล้ายกันหรืออะไรก็ตาม เอนทิตีเฟรมเวิร์กคอร์ - สวรรค์สำหรับนักพัฒนา โดยที่คุณไม่ต้องกังวลกับการเขียนสคริปต์ SQL แต่อธิบายแบบสอบถามในฐานข้อมูลในรูปแบบ OOP แต่แล้ว ในระหว่างการอภิปรายเรื่องแผนปฏิบัติการ ฉันมองดูสแต็กนี้ราวกับว่าเป็นอักษรสุเมเรียน โดยรู้จักเฉพาะ PostgreSQL และ Git เท่านั้น
ตอนนั้นเรากำลังใช้งานอยู่ หุ่นเชิด เป็นระบบการจัดการการกำหนดค่า ในโครงการส่วนใหญ่ของเราที่เราใช้ GitLab CI, ยืดหยุ่นได้, บริการโหลดสูงที่สมดุลโดยใช้ HAProxy ติดตามทุกอย่างด้วย Zabbix,เส้นเอ็น กราฟาน่า и โพร, Jaegerและทั้งหมดนี้ก็ปั่นอยู่บนเศษเหล็ก HP c อีเอสซี บน VMware. ทุกคนรู้ดี - เป็นแนวคลาสสิก
ลองมาดูและพยายามทำความเข้าใจว่าเกิดอะไรขึ้นก่อนที่เราจะเริ่มการแทรกแซงทั้งหมดนี้
เกิดอะไรขึ้น
TFS เป็นระบบที่ค่อนข้างทรงพลังซึ่งไม่เพียงแต่ส่งโค้ดจากนักพัฒนาไปยังเครื่องจักรที่ใช้งานจริงในขั้นสุดท้ายเท่านั้น แต่ยังมีชุดสำหรับการบูรณาการที่ยืดหยุ่นมากกับบริการต่างๆ เพื่อมอบ CI ในระดับข้ามแพลตฟอร์ม
ก่อนหน้านี้เป็นหน้าต่างทึบ TFS ใช้ตัวแทน Build หลายตัว ซึ่งใช้ในการประกอบหลายโครงการ เจ้าหน้าที่แต่ละรายมีคนงาน 3-4 คนเพื่อทำงานแบบขนานและปรับกระบวนการให้เหมาะสม จากนั้น ตามแผนการวางจำหน่าย TFS ได้ส่งมอบ Build ที่เพิ่งสร้างใหม่ไปยังแอปพลิเคชันเซิร์ฟเวอร์ Windows
เราต้องการบรรลุอะไร?
เราใช้ TFS สำหรับการส่งมอบและการพัฒนา และรันแอปพลิเคชันบนเซิร์ฟเวอร์แอปพลิเคชัน Linux และมีความมหัศจรรย์บางอย่างระหว่างทั้งสอง นี้ กล่องวิเศษ และมีเกลือของงานอยู่ข้างหน้า ก่อนที่ฉันจะแยกชิ้นส่วน ฉันจะเว้นวรรคและพูดสักสองสามคำเกี่ยวกับแอปพลิเคชันนี้
โครงการ
แอปพลิเคชั่นนี้มีฟังก์ชันสำหรับการจัดการบัตรเติมเงิน
ไคลเอนต์
มีผู้ใช้สองประเภท แรก เข้าถึงได้โดยการเข้าสู่ระบบโดยใช้ใบรับรอง SSL SHA-2 ยู ที่สอง มีการเข้าถึงโดยใช้ข้อมูลเข้าสู่ระบบและรหัสผ่าน
HAProxy
จากนั้นคำขอไคลเอ็นต์ไปที่ HAProxy ซึ่งแก้ไขปัญหาต่อไปนี้:
- การอนุญาตเบื้องต้น
- การยกเลิก SSL;
- ปรับแต่งคำขอ HTTP;
- คำขอออกอากาศ
ใบรับรองไคลเอ็นต์ได้รับการตรวจสอบตลอดสาย เรา - ผู้มีอำนาจ และเราสามารถจ่ายได้ เนื่องจากเราเองเป็นผู้ออกใบรับรองให้กับลูกค้าที่ให้บริการ
ให้ความสนใจกับประเด็นที่สามเราจะกลับมาดูอีกครั้งในภายหลัง
แบ็กเอนด์
พวกเขาวางแผนที่จะสร้างแบ็กเอนด์บน Linux แบ็กเอนด์โต้ตอบกับฐานข้อมูล โหลดรายการสิทธิ์ที่จำเป็น จากนั้นให้สิทธิ์เข้าถึงเพื่อลงนามในเอกสารทางการเงินและส่งเพื่อดำเนินการ หรือสร้างรายงานบางประเภท ขึ้นอยู่กับสิทธิ์ที่ผู้ใช้ที่ได้รับอนุญาตมี
ประหยัดด้วย HAProxy
นอกเหนือจากสองบริบทที่ลูกค้าแต่ละรายสำรวจแล้ว ยังมีบริบทข้อมูลประจำตัวอีกด้วย IdentityServer4 เพียงอนุญาตให้คุณเข้าสู่ระบบนี่เป็นอะนาล็อกฟรีและทรงพลังสำหรับ ADFS - บริการสหพันธรัฐไดเรกทอรีที่ใช้งานอยู่.
คำขอระบุตัวตนได้รับการประมวลผลในหลายขั้นตอน ขั้นแรก - ลูกค้า เข้าไปในแบ็กเอนด์ซึ่งสื่อสารกับเซิร์ฟเวอร์นี้และตรวจสอบการมีอยู่ของโทเค็นสำหรับไคลเอนต์ หากไม่พบ คำขอจะถูกส่งกลับไปยังบริบทที่มา แต่ด้วยการเปลี่ยนเส้นทาง และด้วยการเปลี่ยนเส้นทาง คำขอจะไปยังข้อมูลระบุตัวตน
ขั้นตอนที่สอง - ได้รับคำขอแล้ว ไปที่หน้าการอนุญาตใน IdentityServer ที่ที่ลูกค้าลงทะเบียน และโทเค็นที่รอคอยมานานนั้นปรากฏในฐานข้อมูล IdentityServer
ขั้นตอนที่สาม - ลูกค้าถูกเปลี่ยนเส้นทางกลับ ไปสู่บริบทที่มันเกิดขึ้น
IdentityServer4 มีคุณสมบัติ: มันส่งคืนการตอบสนองต่อคำขอส่งคืนผ่าน HTTP. ไม่ว่าเราจะดิ้นรนกับการตั้งค่าเซิร์ฟเวอร์มากน้อยเพียงใด ไม่ว่าเราจะให้ความกระจ่างแจ้งกับเอกสารมากน้อยเพียงใด แต่ละครั้งที่เราได้รับคำขอไคลเอนต์เริ่มแรกด้วย URL ที่มาจาก HTTPS และ IdentityServer ส่งคืนบริบทเดียวกัน แต่ด้วย HTTP เราตกใจมาก! และเราถ่ายโอนทั้งหมดนี้ผ่านบริบทข้อมูลประจำตัวไปยัง HAProxy และในส่วนหัว เราต้องแก้ไขโปรโตคอล HTTP เป็น HTTPS
การปรับปรุงคืออะไรและคุณประหยัดได้ที่ไหน?
เราประหยัดเงินโดยใช้โซลูชันฟรีสำหรับการอนุญาตกลุ่มผู้ใช้และทรัพยากร เนื่องจากเราไม่ได้วาง IdentityServer4 เป็นโหนดแยกต่างหากในเซ็กเมนต์ที่แยกจากกัน แต่ใช้ร่วมกับแบ็กเอนด์บนเซิร์ฟเวอร์เดียวกันกับที่แบ็กเอนด์ของแอปพลิเคชันทำงาน .
มันควรจะทำงานอย่างไร
ตามที่ฉันสัญญาไว้ - Magic Box เราเข้าใจแล้วว่าเรารับประกันว่าจะก้าวไปสู่ Linux มากำหนดงานเฉพาะที่ต้องการวิธีแก้ปัญหากันดีกว่า
การแสดงหุ่นเชิด. ในการส่งมอบและจัดการบริการและการกำหนดค่าแอปพลิเคชัน จำเป็นต้องเขียนสูตรอาหารเด็ดๆ ม้วนดินสอแสดงให้เห็นอย่างชัดเจนถึงความรวดเร็วและมีประสิทธิภาพ
วิธีการจัดส่ง มาตรฐานคือ RPM ทุกคนเข้าใจดีว่าใน Linux คุณไม่สามารถทำได้หากไม่มีมัน แต่ตัวโครงการเองหลังจากการประกอบแล้วนั้นเป็นชุดของไฟล์ DLL ที่ปฏิบัติการได้ มีประมาณ 150 คน โครงการนี้ค่อนข้างยาก ทางออกเดียวที่กลมกลืนกันคือรวมไบนารี่นี้ไว้ใน RPM และปรับใช้แอปพลิเคชันจากไบนารีนั้น
การกำหนดเวอร์ชัน เราต้องออกบ่อยมาก และเราต้องตัดสินใจว่าจะสร้างชื่อแพ็คเกจอย่างไร นี่เป็นคำถามเกี่ยวกับระดับของการบูรณาการกับ TFS เรามีตัวแทนการสร้างบน Linux เมื่อ TFS ส่งงานไปยังตัวจัดการ - ผู้ปฏิบัติงาน - ไปยังตัวแทน Build มันจะส่งผ่านตัวแปรจำนวนมากที่จบลงในสภาพแวดล้อมของกระบวนการตัวจัดการ ตัวแปรสภาพแวดล้อมเหล่านี้ประกอบด้วยชื่อบิลด์ ชื่อเวอร์ชัน และตัวแปรอื่นๆ อ่านเพิ่มเติมเกี่ยวกับสิ่งนี้ในส่วน “การสร้างแพ็คเกจ RPM”
การตั้งค่า TFS ลงมาตั้ง Pipeline ก่อนหน้านี้เราได้รวบรวมโปรเจ็กต์ Windows ทั้งหมดบนเอเจนต์ Windows แต่ตอนนี้เอเจนต์ Linux ปรากฏขึ้น - เอเจนต์ Build ซึ่งจำเป็นต้องรวมอยู่ในกลุ่มการ build เสริมด้วยสิ่งประดิษฐ์บางอย่าง และบอกว่าโปรเจ็กต์ประเภทใดที่จะถูกสร้างขึ้นบนเอเจนต์ Build นี้ และปรับเปลี่ยน Pipeline ด้วยวิธีใดวิธีหนึ่ง
IdentityServer. ADFS ไม่ใช่ทางของเรา เรากำลังมุ่งสู่ Open Source
มาดูส่วนประกอบกัน
กล่องวิเศษ
ประกอบด้วยสี่ส่วน
เอเจนต์ Linux Build Linux เพราะเราสร้างมาเพื่อมัน - มันสมเหตุสมผล ส่วนนี้เสร็จสิ้นในสามขั้นตอน
- กำหนดค่าผู้ปฏิบัติงาน และไม่ใช่คนเดียว เนื่องจากคาดว่าจะมีการกระจายงานในโครงการนี้
- ติดตั้ง .NET Core 1.x. ทำไมต้อง 1.x เมื่อ 2.0 มีอยู่แล้วในพื้นที่เก็บข้อมูลมาตรฐาน เพราะเมื่อเราเริ่มพัฒนา เวอร์ชันเสถียรคือ 1.09 และมีการตัดสินใจที่จะสร้างโปรเจ็กต์ตามนั้น
- คอมไพล์ 2.x.
ที่เก็บ RPM จำเป็นต้องจัดเก็บแพ็คเกจ RPM ไว้ที่ใดที่หนึ่ง สันนิษฐานว่าเราจะใช้พื้นที่เก็บข้อมูล RPM ขององค์กรเดียวกันกับโฮสต์ Linux ทั้งหมด นั่นคือสิ่งที่พวกเขาทำ เซิร์ฟเวอร์ที่เก็บได้รับการกำหนดค่าแล้ว webhook ซึ่งดาวน์โหลดแพ็คเกจ RPM ที่ต้องการจากตำแหน่งที่ระบุ เวอร์ชันแพ็กเกจถูกรายงานไปยัง webhook โดยตัวแทน Build
GitLab ความสนใจ! GitLab ที่นี่ไม่ได้ใช้โดยนักพัฒนา แต่โดยฝ่ายปฏิบัติการเพื่อควบคุมเวอร์ชันของแอปพลิเคชัน เวอร์ชันของแพ็คเกจ ตรวจสอบสถานะของเครื่อง Linux ทั้งหมด และจัดเก็บสูตร - รายการ Puppet ทั้งหมด
หุ่นเชิด — แก้ไขปัญหาข้อขัดแย้งทั้งหมดและส่งมอบการกำหนดค่าที่เราต้องการจาก Gitlab อย่างแน่นอน
เราเริ่มดำน้ำ การส่ง DLL ไปยัง RPM ทำงานอย่างไร
จัดส่ง DDL ถึง RPM
สมมติว่าเรามีดาราดังด้านการพัฒนา .NET ใช้ Visual Studio และสร้างสาขาการเผยแพร่ หลังจากนั้นจะอัปโหลดไปยัง Git และ Git นี่คือเอนทิตี TFS นั่นคือเป็นที่เก็บแอปพลิเคชันที่นักพัฒนาทำงานด้วย
หลังจากนั้น TFS ก็เห็นว่า Commit ใหม่เข้ามาแล้ว แอพไหน? ในการตั้งค่า TFS จะมีป้ายกำกับระบุว่าตัวแทน Build เฉพาะมีทรัพยากรใดบ้าง ในกรณีนี้ เขาเห็นว่าเรากำลังสร้างโปรเจ็กต์ .NET Core และเลือกเอเจนต์ Linux Build จากพูล
Build agent จะได้รับแหล่งที่มาและดาวน์โหลดสิ่งที่จำเป็น การอ้างอิง จากที่เก็บ .NET, npm ฯลฯ และหลังจากสร้างแอปพลิเคชันและแพ็กเกจตามมาแล้ว ให้ส่งแพ็กเกจ RPM ไปยังที่เก็บ RPM
ในทางกลับกัน สิ่งต่อไปนี้จะเกิดขึ้น วิศวกรฝ่ายปฏิบัติการมีส่วนร่วมโดยตรงในการเปิดตัวโครงการ โดยเขาเปลี่ยนเวอร์ชันของแพ็คเกจ เฮียรา ในพื้นที่เก็บข้อมูลที่เก็บสูตรแอปพลิเคชันไว้ หลังจากนั้น Puppet จะทริกเกอร์ ยำดึงแพ็คเกจใหม่จากที่เก็บ และแอปพลิเคชันเวอร์ชันใหม่ก็พร้อมใช้งาน
ทุกอย่างเรียบง่ายในคำพูด แต่จะเกิดอะไรขึ้นภายใน Build agent เอง?
บรรจุภัณฑ์ DLL RPM
รับแหล่งที่มาของโครงการและสร้างงานจาก TFS ตัวแทนสร้าง เริ่มสร้างโครงการจากแหล่งที่มา. โปรเจ็กต์ที่ประกอบมีจำหน่ายเป็นชุด ไฟล์ DLLซึ่งบรรจุอยู่ในไฟล์ zip เพื่อลดภาระบนระบบไฟล์
ไฟล์ ZIP จะถูกโยนทิ้งไป ไปยังไดเร็กทอรีการสร้างแพ็คเกจ RPM จากนั้น สคริปต์ Bash จะเริ่มต้นตัวแปรสภาพแวดล้อม ค้นหาเวอร์ชัน Build เวอร์ชันโปรเจ็กต์ พาธไปยังไดเร็กทอรี build และรัน RPM-build เมื่อ build เสร็จสมบูรณ์ แพ็คเกจจะถูกเผยแพร่ไปยัง พื้นที่เก็บข้อมูลในเครื่องซึ่งอยู่บนตัวแทน Build
ถัดไป จาก Build agent ไปยังเซิร์ฟเวอร์ในที่เก็บ RPM ส่งคำขอ JSON แล้ว ระบุชื่อเวอร์ชันและบิลด์ Webhook ที่ฉันพูดถึงก่อนหน้านี้ ดาวน์โหลดแพ็คเกจนี้จากพื้นที่เก็บข้อมูลในเครื่องบน Build agent และทำให้ชุดประกอบใหม่พร้อมสำหรับการติดตั้ง
เหตุใดแผนการจัดส่งแพ็กเกจนี้โดยเฉพาะไปยังที่เก็บ RPM เหตุใดฉันจึงไม่สามารถส่งแพ็คเกจที่ประกอบแล้วไปยังที่เก็บได้ทันที ความจริงก็คือนี่เป็นเงื่อนไขในการรับรองความปลอดภัย สถานการณ์นี้จำกัดความเป็นไปได้ที่บุคคลที่ไม่ได้รับอนุญาตจะอัพโหลดแพ็คเกจ RPM ไปยังเซิร์ฟเวอร์ที่เครื่อง Linux ทุกเครื่องสามารถเข้าถึงได้
การกำหนดเวอร์ชันฐานข้อมูล
ในการปรึกษาหารือกับทีมพัฒนา ปรากฎว่าคนเหล่านี้มีความใกล้ชิดกับ MS SQL มากขึ้น แต่ในโครงการส่วนใหญ่ที่ไม่ใช่ Windows เราใช้ PostgreSQL อย่างเต็มความสามารถอยู่แล้ว เนื่องจากเราได้ตัดสินใจที่จะละทิ้งทุกสิ่งที่จ่ายไป เราจึงเริ่มใช้ PostgreSQL ที่นี่ด้วย
ในส่วนนี้ ฉันอยากจะบอกคุณว่าเรากำหนดเวอร์ชันฐานข้อมูลอย่างไร และเราจะเลือกระหว่าง Flyway และ Entity Framework Core อย่างไร ลองดูข้อดีข้อเสียของพวกเขา
cons
Flyway ไปได้ทางเดียวเท่านั้นเรา เราไม่สามารถย้อนกลับไปได้ - นี่เป็นข้อเสียเปรียบที่สำคัญ คุณสามารถเปรียบเทียบกับ Entity Framework Core ได้ด้วยวิธีอื่น - ในแง่ของความสะดวกของนักพัฒนา คุณจำได้ว่าเราให้ความสำคัญกับสิ่งนี้เป็นอันดับแรก และเกณฑ์หลักคือไม่ต้องเปลี่ยนแปลงสิ่งใดสำหรับการพัฒนา Windows
สำหรับฟลายเวย์เรา จำเป็นต้องมีกระดาษห่อบางชนิดเพื่อไม่ให้ผู้ชายเขียน แบบสอบถาม SQL. พวกเขาใกล้เคียงกับการดำเนินงานในแง่ OOP มาก เราเขียนคำแนะนำสำหรับการทำงานกับออบเจ็กต์ฐานข้อมูล สร้างแบบสอบถาม SQL และดำเนินการ ฐานข้อมูลเวอร์ชันใหม่พร้อมทดสอบแล้ว - ทุกอย่างเรียบร้อยดีทุกอย่างใช้งานได้
Entity Framework Core มีข้อเสีย - ภายใต้ภาระหนัก สร้างแบบสอบถาม SQL ที่ไม่เหมาะที่สุดและการขาดทุนในฐานข้อมูลอาจมีนัยสำคัญ แต่เนื่องจากเราไม่มีบริการที่มีภาระงานสูง เราจึงไม่คำนวณภาระงานเป็นร้อย RPS เราจึงยอมรับความเสี่ยงเหล่านี้และมอบหมายปัญหาให้กับเราในอนาคต
ข้อดี
เอนทิตีเฟรมเวิร์กคอร์ ทำงานนอกกรอบและง่ายต่อการพัฒนาและทางฟลายเวย์ รวมเข้ากับ CI ที่มีอยู่ได้อย่างง่ายดาย. แต่เราทำให้มันสะดวกสำหรับนักพัฒนา :)
ขั้นตอนการโรลอัพ
หุ่นเชิดเห็นว่ามีการเปลี่ยนแปลงในเวอร์ชันแพ็คเกจ รวมถึงเวอร์ชันที่รับผิดชอบในการโยกย้ายด้วย ขั้นแรก จะติดตั้งแพ็คเกจที่มีสคริปต์การย้ายข้อมูลและฟังก์ชันที่เกี่ยวข้องกับฐานข้อมูล หลังจากนี้ แอปพลิเคชันที่ทำงานกับฐานข้อมูลจะรีสตาร์ท ถัดมาคือการติดตั้งส่วนประกอบที่เหลือ ลำดับการติดตั้งแพ็คเกจและการเปิดแอปพลิเคชันมีการอธิบายไว้ในรายการ Puppet
แอปพลิเคชันใช้ข้อมูลที่ละเอียดอ่อน เช่น โทเค็น รหัสผ่านฐานข้อมูล ทั้งหมดนี้ถูกดึงไปยังการกำหนดค่าจาก Puppet Master ซึ่งจัดเก็บไว้ในรูปแบบที่เข้ารหัส
ปัญหา TFS
หลังจากที่เราตัดสินใจและตระหนักว่าทุกอย่างได้ผลสำหรับเราจริงๆ ฉันจึงตัดสินใจดูว่าเกิดอะไรขึ้นกับแอสเซมบลีใน TFS โดยรวมสำหรับแผนกพัฒนา Win ในโครงการอื่นๆ ไม่ว่าเราจะสร้าง/ปล่อยอย่างรวดเร็วหรือไม่ก็ตาม และ พบปัญหาสำคัญเกี่ยวกับความเร็ว
หนึ่งในโปรเจ็กต์หลักใช้เวลาประกอบ 12-15 นาที นานมากคุณจะอยู่แบบนั้นไม่ได้ การวิเคราะห์อย่างรวดเร็วแสดงให้เห็นว่า I/O ลดลงอย่างมาก และนี่คือในอาร์เรย์
หลังจากวิเคราะห์ทีละองค์ประกอบแล้ว ฉันจึงระบุจุดโฟกัสได้สามจุด อันดับแรก - "โปรแกรมป้องกันไวรัส Kaspersky"ซึ่งจะสแกนซอร์สบนเอเจนต์ Windows Build ทั้งหมด ที่สอง - Windows ตัวทำดัชนี มันไม่ได้ถูกปิดใช้งาน และทุกอย่างได้รับการจัดทำดัชนีแบบเรียลไทม์บนเอเจนต์ Build ในระหว่างกระบวนการปรับใช้
ที่สาม - ติดตั้ง NPM ปรากฎว่าในไปป์ไลน์ส่วนใหญ่เราใช้สถานการณ์นี้เหมือนกัน ทำไมเขาถึงแย่? ขั้นตอนการติดตั้ง Npm จะทำงานเมื่อมีการสร้างแผนผังการพึ่งพา แพคเกจ lock.jsonโดยที่เวอร์ชันของแพ็กเกจที่จะใช้ในการสร้างโปรเจ็กต์จะถูกบันทึก ข้อเสียคือการติดตั้ง Npm จะดึงแพ็คเกจเวอร์ชันล่าสุดจากอินเทอร์เน็ตทุกครั้ง และการดำเนินการนี้ใช้เวลานานในกรณีของโครงการขนาดใหญ่
บางครั้งนักพัฒนาจะทำการทดลองบนเครื่องท้องถิ่นเพื่อทดสอบว่าส่วนใดส่วนหนึ่งหรือทั้งโครงการทำงานอย่างไร บางครั้งปรากฎว่าทุกอย่างเย็นสบายในท้องถิ่น แต่พวกเขาประกอบมัน ม้วนออก และไม่มีอะไรทำงาน เราเริ่มเข้าใจว่าปัญหาคืออะไร ใช่แล้ว เวอร์ชันต่างๆ ของแพ็คเกจที่มีการขึ้นต่อกัน
การตัดสิน
- แหล่งที่มาในข้อยกเว้น AV
- ปิดการใช้งานการจัดทำดัชนี
- เปลี่ยนไปเป็น เวลา XNUMX น.
ข้อดีของ npm ci คือเรา เรารวบรวมแผนผังการพึ่งพาหนึ่งครั้งและเราได้รับโอกาสในการจัดหานักพัฒนา รายการแพ็คเกจปัจจุบันซึ่งเขาสามารถทดลองในท้องถิ่นได้มากเท่าที่ต้องการ นี้ ประหยัดเวลา นักพัฒนาที่เขียนโค้ด
องค์ประกอบ
ตอนนี้เล็กน้อยเกี่ยวกับการกำหนดค่าพื้นที่เก็บข้อมูล ในอดีตเราใช้ Nexus สำหรับการจัดการที่เก็บข้อมูล ได้แก่ REPO ภายใน. พื้นที่เก็บข้อมูลภายในนี้มีส่วนประกอบทั้งหมดที่เราใช้เพื่อวัตถุประสงค์ภายใน เช่น การตรวจสอบที่เขียนขึ้นเอง
เรายังใช้ นูเก็ทเนื่องจากมีแคชที่ดีกว่าเมื่อเปรียบเทียบกับตัวจัดการแพ็คเกจอื่น
ผล
หลังจากที่เราปรับ Build Agents ให้เหมาะสมแล้ว เวลาในการสร้างโดยเฉลี่ยลดลงจาก 12 นาทีเหลือ 7 นาที
หากเรานับเครื่องทั้งหมดที่เราสามารถใช้ได้สำหรับ Windows แต่เปลี่ยนมาใช้ Linux ในโปรเจ็กต์นี้ เราก็ประหยัดเงินได้ประมาณ 10 เหรียญสหรัฐ และนั่นเป็นเพียงใบอนุญาตเท่านั้น และมากกว่านั้นหากเราคำนึงถึงเนื้อหาด้วย
แผน
สำหรับไตรมาสหน้า เราวางแผนที่จะเพิ่มประสิทธิภาพการจัดส่งโค้ด
การสลับไปใช้อิมเมจ Docker ที่สร้างไว้ล่วงหน้า. TFS เป็นสิ่งดีๆ ที่มีปลั๊กอินมากมายที่ช่วยให้คุณสามารถรวมเข้ากับ Pipeline ได้ รวมถึงแอสเซมบลีแบบทริกเกอร์ เช่น อิมเมจ Docker เราต้องการสร้างทริกเกอร์นี้สำหรับอันเดียวกัน แพคเกจ lock.json. หากองค์ประกอบของส่วนประกอบที่ใช้สร้างโปรเจ็กต์มีการเปลี่ยนแปลง เราจะสร้างอิมเมจ Docker ใหม่ จะใช้ในภายหลังเพื่อปรับใช้คอนเทนเนอร์ด้วยแอปพลิเคชันที่ประกอบขึ้น ขณะนี้ไม่เป็นเช่นนั้น แต่เรากำลังวางแผนที่จะเปลี่ยนไปใช้สถาปัตยกรรมไมโครเซอร์วิสใน Kubernetes ซึ่งกำลังพัฒนาอย่างแข็งขันในบริษัทของเราและให้บริการโซลูชันการผลิตมาเป็นเวลานาน
สรุป
ฉันสนับสนุนให้ทุกคนทิ้ง Windows แต่ไม่ใช่เพราะฉันทำอาหารไม่เป็น เหตุผลก็คือโซลูชัน Opensource ส่วนใหญ่เป็นเช่นนั้น สแต็คลินุกซ์. คุณสบายดีไหม ประหยัดทรัพยากร. ในความคิดของฉัน อนาคตเป็นของโซลูชันโอเพ่นซอร์สบน Linux พร้อมชุมชนที่ทรงพลัง
โปรไฟล์วิทยากรของ Alexander Sinchinov .
เป็นการประชุมบูรณาการกระบวนการพัฒนา การทดสอบ และการดำเนินงานสำหรับมืออาชีพโดยผู้เชี่ยวชาญ นั่นเป็นสาเหตุที่โครงการที่อเล็กซานเดอร์พูดถึง? นำไปใช้และทำงานและในวันที่มีการแสดงก็มีการเผยแพร่ที่ประสบความสำเร็จสองครั้ง บน ในวันที่ 27 และ 28 พฤษภาคม จะมีกรณีที่คล้ายกันจากผู้ปฏิบัติงานมากยิ่งขึ้น คุณยังคงสามารถกระโดดเข้าไปในรถม้าคันสุดท้ายและ หรือใช้เวลาของคุณ ตั๋ว. พบกับเราที่สโกลโคโว!
ที่มา: will.com