ทำไมฉันต้องใช้ MSBuild แทนไฟล์ Visual Studio Solution

เรากำลังใช้ TeamCity เพื่อการรวมอย่างต่อเนื่องและมันกำลังสร้างการเผยแพร่ของเราผ่านทางไฟล์โซลูชัน (.sln) ฉันเคยใช้ Makefiles ในอดีตสำหรับระบบต่าง ๆ แต่ไม่เคย msbuild (ซึ่งฉันได้ยินมาว่า sorta เหมือนกับ Makefiles + XML mashup) ฉันเห็นโพสต์มากมายเกี่ยวกับวิธีใช้ msbuild โดยตรงแทนที่จะเป็นไฟล์โซลูชัน แต่ฉันไม่เห็นคำตอบที่ชัดเจนว่าทำไมต้องทำ

เหตุใดเราจึงต้องกังวลเกี่ยวกับการย้ายจากไฟล์โซลูชันไปยัง 'ไฟล์' ของ MSBuild เรามีสองรุ่นที่แตกต่างกันโดย #define (สร้างความน่าเชื่อถือ) แต่ส่วนใหญ่แล้วทุกอย่างทำงานได้

ข้อกังวลที่ใหญ่กว่าคือตอนนี้เราต้องบำรุงรักษาสองระบบเมื่อเพิ่มโปรเจ็กต์ / ซอร์สโค้ด

UPDATE:

ผู้คนสามารถมองเห็นวงจรชีวิตและการทำงานร่วมกันขององค์ประกอบทั้งสามต่อไปนี้ได้หรือไม่?

1. ไฟล์. sln ของ Visual Studio
2. หลายระดับโครงการไฟล์. csproj (ซึ่งฉันเข้าใจสคริปต์ msbuild "sub")
3. สคริปต์ msbuild ที่กำหนดเอง

มันปลอดภัยหรือไม่ที่จะบอกว่า. sln และ. csproj ถูกบริโภค / ดูแลรักษาตามปกติจากภายใน Visual Studio IDE GUI ในขณะที่สคริปต์ msbuild ที่กำหนดเองนั้นเขียนด้วยมือ นั่นเป็นวิธีหนึ่งที่ฉันสามารถเห็นการทับซ้อน / ซ้ำซ้อนในการบำรุงรักษา ...

จะขอบคุณบางอย่างเกี่ยวกับเรื่องนี้จากประสบการณ์การดำเนินงานของคนอื่น

จุดแรกของความจริงก็คือไฟล์โซลูชันจะกลายเป็นไฟล์ MSBuild อย่างน่าอัศจรรย์เมื่อ MSBuild ดำเนินการซึ่งเป็นสิ่งที่เกิดขึ้นเมื่อคุณสร้างโซลูชันใน Visual Studio นอกจากนี้ไฟล์โครงการเหล่านั้นทั้งหมดเป็นเพียงไฟล์ msbuild ที่จัดการโดย Visual Studio อันที่จริงแล้วไฟล์โครงการจะจัดการงานสกปรกที่แท้จริงส่วนใหญ่ที่นี่ไม่ว่าคุณจะสร้างจากโซลูชันหรือสิ่งปลูกสร้างจากสคริปต์ msbuild ที่กำหนดเอง

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

makefile สำหรับ msbuild เป็นไฟล์. sln (หรือไฟล์ vcproj)

บรรทัดคำสั่ง msbuild ทั่วไปจะเป็นสิ่งที่ต้องการ:

msbuild /p:Configuration=Release BigProject.sln

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

ฉันขอเสนอคำถามของฉัน

แม้ว่าคุณจะสามารถใช้ไฟล์. SLN ของคุณเป็น 'กระบวนการสร้าง' ได้ แต่ตัวไฟล์เองก็ไม่ได้เป็นกระบวนการสร้าง ไฟล์โซลูชันเป็นเพียงส่วนหนึ่งของ Visual Studio และใช้สำหรับการพัฒนา แต่ Visual Studio เป็นเพียงส่วนหนึ่งของกระบวนการสร้างและวางจำหน่าย คุณไม่สามารถพึ่งพาโซลูชันในการจัดการงานสร้างของคุณได้และแน่นอนว่าโซลูชันจะไม่นำเสนอสถานการณ์การปรับขนาดที่ปรับขนาดได้

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

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

• ผลิตภัณฑ์ของคุณมีหลายทีม (ข้ามสายงานหรืออื่น ๆ ) ที่ทำงานในโครงการทีมเดียวกัน
• องค์กรของคุณมีโครงการของทีมเพียงโครงการเดียว (ควรเป็นกรณี 99% ของร้านค้าแบบดั้งเดิมแม้แต่ที่มีนักพัฒนากว่า 200 คน)
• คุณมีโครงการมากกว่า 20 โครงการที่จำเป็นต้องสร้างขึ้นบางโครงการมีการพึ่งพาผู้อื่นและดูแลโดยทีมต่าง ๆ
• ผลิตภัณฑ์ของคุณประกอบด้วยเทคโนโลยี. NET หลายรายการ (C #, C ++, VB, F #, ASP.NET, ฯลฯ ) หรือแม้กระทั่งเทคโนโลยีที่ไม่ใช่ NET (Grunt, node, npm, Java, etc)
• ผลิตภัณฑ์ของคุณมีการขึ้นต่อกันหนาหรือถูกสร้างขึ้นบนแพลตฟอร์มเฮฟวี่เวท SharePoint เป็นตัวอย่าง

ให้ฉันยกตัวอย่างเพื่อขยายในจุดสุดท้ายของฉัน บริษัท ปัจจุบันของฉันทำการพัฒนา SharePoint การพัฒนา SharePoint อย่างน้อยต้องมีการติดตั้ง SharePoint พื้นฐานเพื่อดำเนินการสร้างในโครงการ SharePoint การพูดในแง่ของเซิร์ฟเวอร์บิลด์ที่มีน้ำหนักเบานั้นเป็นไปไม่ได้เลยที่จะกำหนดให้เซิร์ฟเวอร์บิลด์ติดตั้ง SharePoint SharePoint ไม่เพียงเป็นสัตว์ร้ายที่มีความต้องการสูง แต่จะมีผลกระทบต่อประสิทธิภาพการทำงานอย่างมากในการสร้าง - และการสร้างจะต้องรวดเร็วและมีประสิทธิภาพมากที่สุด การใช้ประโยชน์จาก MSBuild ทำให้ฉันสามารถกำจัดข้อกำหนดการติดตั้งนี้บนบิลด์เซิร์ฟเวอร์ ในความเป็นจริงเซิร์ฟเวอร์การสร้างของเราไม่มีข้อกำหนดการติดตั้งอื่นนอกจาก. NET Framework (ต้องการโดย MSBuild) และโหนด

เป็นข้อมูลอ้างอิงฉันขอแนะนำให้ตรวจสอบหนังสือเล่มนี้โดย Sayed Ibrahim Hashimi: http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie=UTF8&qid=1412014650&sr= 8-1-fkmr0 และคำหลัก = MSBuild + ความน่าเชื่อถือ + สร้าง

นี่เป็นคำถามที่ฉันถามตัวเองเมื่อไม่กี่เดือนที่ผ่านมา! เรามีทุกอย่างที่ตั้งไว้อย่างดี:

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

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

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

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