คุณปรับใช้แอปพลิเคชัน ASP.NET กับเซิร์ฟเวอร์จริงได้อย่างไร

ฉันกำลังมองหาเทคนิค / เครื่องมือต่าง ๆ ที่คุณใช้ในการปรับใช้โครงการแอปพลิเคชันเว็บ ASP.NET ( ไม่ใช่เว็บไซต์ ASP.NET) กับการผลิต?

ฉันสนใจเป็นพิเศษเกี่ยวกับเวิร์กโฟลว์ที่เกิดขึ้นระหว่างเวลาที่เซิร์ฟเวอร์ Continuous Integration Build ของคุณทิ้งไบนารีในบางตำแหน่งและเวลาที่คำขอของผู้ใช้ครั้งแรกกระทบกับไบนารีเหล่านี้

1. คุณใช้เครื่องมือเฉพาะบางอย่างหรือแค่ XCOPY? แอปพลิเคชันเป็นแพ็กเกจอย่างไร (ZIP, MSI, ... )

2. เมื่อแอปพลิเคชันถูกปรับใช้เป็นครั้งแรกคุณจะตั้งค่า App Pool และ Virtual Directory ได้อย่างไร (คุณสร้างด้วยตนเองหรือด้วยเครื่องมือบางอย่าง)

3. เมื่อทรัพยากรแบบคงที่เปลี่ยนไป (CSS, JS หรือไฟล์รูปภาพ) คุณจะปรับใช้แอปพลิเคชันทั้งหมดใหม่หรือเฉพาะทรัพยากรที่แก้ไข แล้วหน้าแอสเซมบลี / ASPX จะเปลี่ยนไปอย่างไร?

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

อย่าลังเลที่จะทำรายการก่อนหน้านี้ให้เสร็จสิ้น

และนี่คือสิ่งที่เราใช้เพื่อปรับใช้แอปพลิเคชัน ASP.NET ของเรา:

1. เราเพิ่มWeb Deployment Projectลงในโซลูชันและตั้งค่าเพื่อสร้างเว็บแอปพลิเคชัน ASP.NET
2. เราเพิ่มโครงการติดตั้ง ( ไม่ใช่โครงการตั้งค่าเว็บ) ลงในโซลูชันและตั้งค่าให้ใช้ผลลัพธ์ของโครงการปรับใช้เว็บ
3. เราเพิ่มการดำเนินการติดตั้งแบบกำหนดเองและในเหตุการณ์ OnInstall เรารันแอสเซมบลี. NET แบบกำหนดเองที่สร้าง App Pool และ Virtual Directory ใน IIS โดยใช้System.DirectoryServices.DirectoryEntry (งานนี้จะดำเนินการในครั้งแรกที่มีการปรับใช้แอ็พพลิเคชันเท่านั้น) . เราสนับสนุนเว็บไซต์หลายแห่งใน IIS การรับรองความถูกต้องสำหรับไดเรกทอรีเสมือนและการตั้งค่าตัวตนสำหรับ App Pools
4. เราเพิ่มงานที่กำหนดเองใน TFS เพื่อสร้างโครงการติดตั้ง (TFS ไม่รองรับโครงการติดตั้งดังนั้นเราจึงต้องใช้ devenv.exe เพื่อสร้าง MSI)
5. มีการติดตั้ง MSI บนเซิร์ฟเวอร์ที่ใช้งานจริง (หากมี MSI รุ่นก่อนหน้าจะถูกถอนการติดตั้งก่อน)

เรามีโค้ดทั้งหมดที่ติดตั้งใน MSI โดยใช้ Setup Factory หากมีสิ่งที่ต้องเปลี่ยนแปลงเราปรับใช้โซลูชันทั้งหมดใหม่ สิ่งนี้ฟังดูเหมือน overkill สำหรับไฟล์ css แต่มันช่วยให้ทุกสภาพแวดล้อมซิงค์กันอย่างแน่นอนและเรารู้ดีว่ากำลังผลิตอะไรอยู่ (เราปรับใช้กับสภาพแวดล้อมการทดสอบและ uat ทั้งหมดในลักษณะเดียวกัน)

เราดำเนินการปรับใช้กับเซิร์ฟเวอร์ที่ใช้งานจริงดังนั้นเราจึงไม่ใช้โครงการติดตั้ง เรามีบางอย่างที่คล้ายกับ CI:

• บิลด์เซิร์ฟเวอร์ที่สร้าง "live" จากแหล่งที่ได้รับการอนุมัติ (ไม่ใช่ "HEAD" ของ repo)
• (หลังจากทำการสำรองข้อมูลแล้ว ;-p)
• robocopy เผยแพร่ไปยังเซิร์ฟเวอร์การจัดเตรียม ("สด" แต่ไม่ใช่ในคลัสเตอร์ F5)
• การตรวจสอบขั้นสุดท้ายทำบนเซิร์ฟเวอร์การจัดเตรียมโดยมักจะมีการแฮ็ก "โฮสต์" เพื่อเลียนแบบข้อมูลทั้งหมดให้ใกล้เคียงที่สุด
• robocopy / L ถูกใช้โดยอัตโนมัติเพื่อแจกจ่ายรายการการเปลี่ยนแปลงใน "push" ถัดไปเพื่อแจ้งเตือนความผิดใด ๆ
• ในฐานะที่เป็นส่วนหนึ่งของกระบวนการที่กำหนดเวลาคลัสเตอร์จะถูกวนรอบโดยนำไปใช้กับโหนดในคลัสเตอร์ผ่าน robocopy (ในขณะที่อยู่นอกคลัสเตอร์)

robocopy โดยอัตโนมัติทำให้มั่นใจได้ว่ามีการปรับใช้เฉพาะการเปลี่ยนแปลงเท่านั้น

Re the App Pool ฯลฯ ; ฉันชอบที่จะเป็นแบบอัตโนมัติ ( ดูคำถามนี้ ) แต่ในขณะนี้เป็นแบบแมนนวล ฉันอยากจะเปลี่ยนสิ่งนั้นจริงๆ

(อาจช่วยได้ที่เรามีศูนย์ข้อมูลและเซิร์ฟเวอร์ฟาร์ม "ในไซต์" ของเราเองดังนั้นเราจึงไม่ต้องข้ามอุปสรรคมากมาย)

เว็บไซต์

Deployer: http://www.codeproject.com/KB/install/deployer.aspx

ฉันเผยแพร่เว็บไซต์ไปยังโฟลเดอร์ในเครื่องแล้วบีบอัดจากนั้นอัปโหลดผ่าน FTP Deployer บนเซิร์ฟเวอร์จากนั้นแตกไฟล์ zip แทนที่ค่า config (ใน Web.Config และไฟล์อื่น ๆ ) เท่านี้เอง

แน่นอนสำหรับการรันครั้งแรกคุณต้องเชื่อมต่อกับเซิร์ฟเวอร์และตั้งค่า IIS WebSite ฐานข้อมูล แต่หลังจากนั้นการอัปเดตการเผยแพร่ก็เป็นเรื่องง่าย

ฐานข้อมูล

สำหรับการซิงค์ฐานข้อมูลฉันใช้http://www.red-gate.com/products/sql-development/sql-compare/

หากเซิร์ฟเวอร์อยู่หลังเราเตอร์จำนวนมากและคุณไม่สามารถเชื่อมต่อโดยตรง (ซึ่งเป็นข้อกำหนดของ SQL Compare) ให้ใช้https://secure.logmein.com/products/hamachi2/เพื่อสร้าง VPN

ฉันปรับใช้แอป ASP.NET เป็นส่วนใหญ่กับเซิร์ฟเวอร์ Linux และปรับใช้ทุกอย่างเพื่อการเปลี่ยนแปลงที่เล็กที่สุด นี่คือขั้นตอนการทำงานมาตรฐานของฉัน:

• ฉันใช้ที่เก็บซอร์สโค้ด (เช่นการโค่นล้ม)
• บนเซิร์ฟเวอร์ฉันมีสคริปต์ทุบตีที่ทำสิ่งต่อไปนี้:
  • ตรวจสอบรหัสล่าสุด
  • สร้าง (สร้าง DLL)
  • กรองไฟล์ตามข้อมูลสำคัญ (เช่นลบไฟล์โค้ด)
  • สำรองฐานข้อมูล
  • ปรับใช้ไฟล์ไปยังเว็บเซิร์ฟเวอร์ในไดเร็กทอรีที่ตั้งชื่อด้วยวันที่ปัจจุบัน
  • อัพเดตฐานข้อมูลหากสคีมาใหม่รวมอยู่ในการปรับใช้
  • ทำให้การติดตั้งใหม่เป็นค่าเริ่มต้นเพื่อให้การติดตั้งครั้งต่อไป

การชำระเงินเสร็จสิ้นด้วยเวอร์ชันบรรทัดคำสั่งของการโค่นล้มและการสร้างเสร็จสิ้นด้วย xbuild (msbuild ทำงานเหมือนกันจากโปรเจ็กต์ Mono) เวทมนตร์ส่วนใหญ่จะทำใน ReleaseIt

บนเซิร์ฟเวอร์ dev ของฉันฉันมีการรวมอย่างต่อเนื่องเป็นหลัก แต่ในด้านการผลิตฉัน SSH เข้ากับเซิร์ฟเวอร์และเริ่มการปรับใช้ด้วยตนเองโดยการรันสคริปต์ สคริปต์ของฉันถูกเรียกอย่างชาญฉลาดว่า 'ปรับใช้' ดังนั้นนั่นคือสิ่งที่ฉันพิมพ์ที่พรอมต์ทุบตี ฉันมีความคิดสร้างสรรค์มาก ไม่.

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

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

เป็นทางออกที่ดีสำหรับฉันและอาศัยเฉพาะยูทิลิตี้บรรทัดคำสั่งสามรายการ (svn, xbuild และ releaseit) ไคลเอ็นต์ DB SSH และ Bash

ฉันต้องการอัปเดตสำเนาของ ReleaseIt บน CodePlex ในบางครั้ง:

http://releaseit.codeplex.com/

XCopy อย่างง่ายสำหรับ ASP.NET ซิปขึ้น sftp ไปยังเซิร์ฟเวอร์แยกไปยังตำแหน่งที่ถูกต้อง สำหรับการปรับใช้ครั้งแรกให้ตั้งค่า IIS ด้วยตนเอง

ตอบคำถามของคุณ:

1. XCopy
2. ด้วยตนเอง
3. สำหรับทรัพยากรแบบคงที่เราปรับใช้เฉพาะทรัพยากรที่เปลี่ยนแปลงเท่านั้น
   สำหรับ DLL เราปรับใช้เพจ DLL และ ASPX ที่เปลี่ยนแปลง
4. ใช่และใช่

การทำตัวให้ดีและเรียบง่ายช่วยให้เราปวดหัวได้มาก

คุณใช้เครื่องมือเฉพาะบางอย่างหรือแค่ XCOPY? แอปพลิเคชันเป็นแพ็กเกจอย่างไร (ZIP, MSI, ... )

ในฐานะผู้พัฒนาBuildMasterนี่คือสิ่งที่ฉันใช้ แอปพลิเคชันทั้งหมดสร้างและบรรจุภายในเครื่องมือเป็นสิ่งประดิษฐ์ซึ่งเก็บไว้ภายในเป็นไฟล์ ZIP

เมื่อแอปพลิเคชันถูกปรับใช้เป็นครั้งแรกคุณจะตั้งค่า App Pool และ Virtual Directory ได้อย่างไร (คุณสร้างด้วยตนเองหรือด้วยเครื่องมือบางอย่าง)

ด้วยตนเอง - เราสร้างการควบคุมการเปลี่ยนแปลงภายในเครื่องมือที่เตือนให้เราทราบถึงขั้นตอนที่แน่นอนในการดำเนินการในสภาพแวดล้อมในอนาคตเมื่อแอปพลิเคชันเคลื่อนผ่านสภาพแวดล้อมการทดสอบ สิ่งนี้อาจเป็นไปโดยอัตโนมัติด้วยสคริปต์ PowerShell แบบธรรมดา แต่เราไม่ได้เพิ่มแอปพลิเคชันใหม่บ่อยนักดังนั้นจึงง่ายพอ ๆ กับการใช้เวลา 1 นาทีในการสร้างไซต์ด้วยตนเอง

เมื่อทรัพยากรแบบคงที่เปลี่ยนไป (CSS, JS หรือไฟล์รูปภาพ) คุณจะปรับใช้แอปพลิเคชันทั้งหมดใหม่หรือเฉพาะทรัพยากรที่แก้ไข แล้วหน้าแอสเซมบลี / ASPX จะเปลี่ยนไปอย่างไร?

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

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

ใช่ BuildMaster จัดการทั้งหมดนี้ให้เรา การกู้คืนส่วนใหญ่ทำได้ง่ายเหมือนกับการเรียกใช้โปรโมชั่นบิลด์เก่าอีกครั้ง แต่บางครั้งการเปลี่ยนแปลงฐานข้อมูลจำเป็นต้องได้รับการกู้คืนด้วยตนเองและข้อมูลอาจสูญหายได้ ขั้นตอนการย้อนกลับพื้นฐานมีรายละเอียดที่นี่: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

โครงการติดตั้ง / ติดตั้งเว็บ - คุณจึงสามารถถอนการติดตั้งได้อย่างง่ายดายหากมีสิ่งผิดปกติเกิดขึ้น

Unfoldเป็นโซลูชันการปรับใช้แบบคาปิสตราโนที่ฉันเขียนสำหรับแอปพลิเคชัน. net เป็นสิ่งที่เราใช้ในโครงการทั้งหมดของเราและเป็นโซลูชันที่ยืดหยุ่นมาก ช่วยแก้ปัญหาทั่วไปส่วนใหญ่สำหรับแอปพลิเคชัน. netตามที่ Rob Coneryอธิบายไว้ในบล็อกโพสต์นี้

• มันมาพร้อมกับพฤติกรรม "เริ่มต้น" ที่ดีในแง่ที่ว่ามันทำหลายสิ่งหลายอย่างมาตรฐานสำหรับคุณ: รับรหัสจากการควบคุมแหล่งที่มา, การสร้าง, การสร้างพูลแอปพลิเคชัน, การตั้งค่า IIS ฯลฯ
• เผยแพร่ตามสิ่งที่อยู่ในการควบคุมแหล่งที่มา
• มีตะขอเกี่ยวงานดังนั้นพฤติกรรมเริ่มต้นสามารถขยายหรือเปลี่ยนแปลงได้อย่างง่ายดาย
• มันมีการย้อนกลับ
• มันเป็นพาวเวอร์เชลล์ทั้งหมดดังนั้นจึงไม่มีการอ้างอิงภายนอกใด ๆ
• มันใช้ powershell remoting เพื่อเข้าถึงเครื่องระยะไกล

นี่คือบทนำและบล็อกโพสต์อื่น ๆ

ดังนั้นเพื่อตอบคำถามด้านบน:

• แอปพลิเคชันเป็นแพ็กเกจอย่างไร (ZIP, MSI, ... )

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

• เมื่อแอปพลิเคชันถูกปรับใช้เป็นครั้งแรกคุณจะตั้งค่า App Pool และ Virtual Directory ได้อย่างไร (คุณสร้างด้วยตนเองหรือด้วยเครื่องมือบางอย่าง)

  Unfold กำหนดค่าพูลแอปพลิเคชันและแอปพลิเคชันเว็บไซต์โดยใช้โมดูลการดูแลระบบเว็บของ Powershell ช่วยให้เรา (และคุณ) สามารถแก้ไขส่วนใด ๆ ของกลุ่มแอปพลิเคชันหรือเว็บไซต์

• เมื่อทรัพยากรแบบคงที่เปลี่ยนไป (CSS, JS หรือไฟล์รูปภาพ) คุณจะปรับใช้แอปพลิเคชันทั้งหมดใหม่หรือเฉพาะทรัพยากรที่แก้ไข แล้วหน้าแอสเซมบลี / ASPX จะเปลี่ยนไปอย่างไร?

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

• คุณติดตามเวอร์ชันที่ปรับใช้ทั้งหมดสำหรับแอปพลิเคชันหนึ่ง ๆ หรือไม่?

  ใช่แฉเก็บเวอร์ชันเก่า ๆ ไม่ใช่ทุกเวอร์ชัน แต่มีหลายเวอร์ชัน มันทำให้การย้อนกลับเป็นเรื่องเล็กน้อย

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

ดังนั้นเมื่อเช็คอินบิลด์ "ปกติ" ของเราจะทำสิ่งต่อไปนี้:

• Jenkins ทำการอัปเดต SVN เพื่อดึงโค้ดเวอร์ชันล่าสุด
• การกู้คืนแพ็กเกจ NuGet เสร็จสิ้นโดยทำงานกับที่เก็บ NuGet ในเครื่องของเราเอง
• แอปพลิเคชันนี้รวบรวมโดยใช้ MsBuild การตั้งค่านี้เป็นการผจญภัยเพราะคุณต้องติดตั้ง MsBuild ที่ถูกต้องจากนั้น ASP.NET และ MVC dll ในกล่องบิลด์ของคุณ (ตามหมายเหตุด้านข้างเมื่อฉัน<MvcBuildViews>true</MvcBuildViews>ป้อนไฟล์. csproj ของฉันเพื่อรวบรวมมุมมอง msbuild เกิดปัญหาแบบสุ่มดังนั้นฉันจึงต้องปิดการใช้งาน)
• เมื่อรวบรวมรหัสแล้วการทดสอบหน่วยจะทำงาน (ฉันใช้แม่ชีสำหรับสิ่งนี้ แต่คุณสามารถใช้อะไรก็ได้ที่คุณต้องการ)
• หากการทดสอบหน่วยทั้งหมดผ่านฉันจะหยุดพูลแอพ IIS ปรับใช้แอพในเครื่อง (คำสั่ง XCOPY พื้นฐานเพียงไม่กี่คำเพื่อคัดลอกไฟล์ที่จำเป็น) จากนั้นรีสตาร์ท IIS (ฉันมีปัญหากับไฟล์ล็อค IIS และสิ่งนี้แก้ไขได้ มัน)
• ฉันมีไฟล์ web.config แยกต่างหากสำหรับแต่ละสภาพแวดล้อม dev, uat, prod. (ฉันลองใช้สิ่งที่เปลี่ยนแปลงเว็บแล้วประสบความสำเร็จเพียงเล็กน้อย) ดังนั้นไฟล์ web.config ที่ถูกต้องจะถูกคัดลอกไปด้วย
• จากนั้นฉันใช้ PhantomJS เพื่อดำเนินการทดสอบ UI จำนวนมาก นอกจากนี้ยังใช้ภาพหน้าจอจำนวนมากด้วยความละเอียดที่แตกต่างกัน (มือถือเดสก์ท็อป) และประทับตราภาพหน้าจอแต่ละภาพพร้อมข้อมูลบางอย่าง (ชื่อหน้าความละเอียด) Jenkins ได้รับการสนับสนุนอย่างดีเยี่ยมในการจัดการภาพหน้าจอเหล่านี้และจะได้รับการบันทึกเป็นส่วนหนึ่งของงานสร้าง
• เมื่อการทดสอบ UI การรวมผ่านการสร้างสำเร็จ

หากมีคนคลิก "ปรับใช้กับ UAT":

• หากการสร้างครั้งล่าสุดสำเร็จ Jenkins จะทำการอัปเดต SVN อีกครั้ง
• แอปพลิเคชันถูกรวบรวมโดยใช้การกำหนดค่าการปล่อย
• ไดเร็กทอรี "www" ถูกสร้างขึ้นและแอปพลิเคชันจะถูกคัดลอกลงในไดเร็กทอรี
• จากนั้นฉันใช้ winscp เพื่อซิงโครไนซ์ระบบไฟล์ระหว่าง build box และ UAT
• ฉันส่งคำขอ HTTP ไปยังเซิร์ฟเวอร์ UAT และตรวจสอบให้แน่ใจว่าได้รับ 200 คืน
• การแก้ไขนี้ถูกแท็กใน SVN เป็น UAT-datetime
• ถ้าเรามาไกลขนาดนี้การสร้างก็สำเร็จ!

เมื่อเราคลิก "Deploy to Prod":

• ผู้ใช้เลือก UAT Tag ที่สร้างไว้ก่อนหน้านี้
• แท็กถูก "เปลี่ยน" เป็น
• โค้ดถูกคอมไพล์และซิงค์กับเซิร์ฟเวอร์ Prod
• คำขอ HTTP ไปยังเซิร์ฟเวอร์ Prod
• การแก้ไขนี้ถูกแท็กใน SVN เป็น Prod-datetime
• รุ่นถูกซิปและจัดเก็บ

การสร้างทั้งหมดจนถึงการผลิตทั้งหมดใช้เวลาประมาณ 30 วินาทีซึ่งฉันมีความสุขมาก

ตรงข้ามกับโซลูชันนี้:

• มันเร็ว
• การทดสอบหน่วยควรตรวจจับข้อผิดพลาดทางตรรกะ
• เมื่อข้อบกพร่องของ UI เข้าสู่การผลิตภาพหน้าจอจะแสดงให้เห็นว่าการแก้ไข # ทำให้เกิดอะไรขึ้น
• UAT และ Prod จะซิงค์กัน
• Jenkins แสดงประวัติการเปิดตัวที่ยอดเยี่ยมสำหรับ UAT และ Prod พร้อมข้อความคอมมิตทั้งหมด
• UAT และ Prod ทุกรุ่นจะถูกแท็กโดยอัตโนมัติ
• คุณสามารถดูได้ว่ามีการเผยแพร่เมื่อใดและใครเป็นผู้ดำเนินการ

ข้อเสียหลักของโซลูชันนี้คือ:

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

ฉันชอบที่จะได้ยินการปรับปรุงที่เป็นไปได้อื่น ๆ !

ย้อนกลับไปในปี 2009 คำตอบนี้มาจากไหนเราใช้ CruiseControl.net สำหรับการสร้างการผสานรวมแบบต่อเนื่องของเราซึ่งส่งออกสื่อเผยแพร่ด้วย

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

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

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

เราใช้ TortoiseSVN สำหรับการควบคุมเวอร์ชันดังนั้นจึงเป็นเรื่องดีที่สามารถเขียนด้วยคำสั่ง SVN หลายคำสั่งเพื่อทำสิ่งต่อไปนี้:

• ก่อนอื่นตรวจสอบว่าผู้ใช้มีการแก้ไขล่าสุด หากไม่เป็นเช่นนั้นให้แจ้งให้อัปเดตหรือเรียกใช้การอัปเดตจากนั้นทันที
• ดาวน์โหลดไฟล์ข้อความจากเซิร์ฟเวอร์ชื่อ "synclog.txt" ที่ให้รายละเอียดว่าใครคือผู้ใช้ SVN หมายเลขแก้ไขที่อัปโหลดและวันที่และเวลาที่อัปโหลด ต่อท้ายบรรทัดใหม่สำหรับการอัปโหลดปัจจุบันแล้วส่งกลับไปที่เซิร์ฟเวอร์พร้อมกับไฟล์ที่เปลี่ยนแปลง สิ่งนี้ทำให้ง่ายมากในการค้นหาว่าควรย้อนกลับไปเป็นเวอร์ชันใดของไซต์หากการอัปโหลดทำให้เกิดปัญหา

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

และสุดท้าย rSync ช่วยให้คุณสำรองไฟล์ที่ถูกแทนที่ระหว่างการอัปโหลด เราได้ย้ายไฟล์เหล่านี้ไปไว้ในโฟลเดอร์สำรองดังนั้นหากคุณรู้ว่าไฟล์บางไฟล์ไม่ควรถูกเขียนทับคุณสามารถค้นหาเวอร์ชันสำรองล่าสุดของทุกไฟล์ในโฟลเดอร์นั้นได้

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

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

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

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