เราจะติดตามเวอร์ชันของรหัสของเราในแต่ละสภาพแวดล้อมได้อย่างไร


14

ขณะนี้ทีมของฉันใช้กระบวนการแยก / ปรับใช้ที่ค่อนข้างง่ายซึ่งมีลักษณะดังนี้:

                ┌────────┐ ┌────┐ ┌──────┐
 Environments:  │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Builds:        │  DEV   │ │ QA │ │ PROD │
                └────────┘ └────┘ └──────┘

                     ▲       ▲       ▲
                     │       │       │

                ┌────────┐ ┌────┐ ┌──────┐
 Branches:      │ master │ │ qa │ │ prod │
                └────────┘ └────┘ └──────┘

แต่ละสภาพแวดล้อมมีสาขาของตัวเอง (เราใช้คอมไพล์ ) และบิลด์ของตัวเองที่ใช้สาขานั้น เมื่อเราต้องการเลื่อนระดับจากสภาพแวดล้อมหนึ่งไปอีกสภาพแวดล้อมหนึ่งเช่นจาก DEV ไปยัง QA เราจะรวมmasterสาขาเข้าqaและเริ่มการสร้าง QA ใหม่ (ซึ่งจะถูกปรับใช้กับสภาพแวดล้อม QA โดยอัตโนมัติ)

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

                ┌────────┐     ┌────┐     ┌──────┐
 Environments:  │  DEV   │ ──► │ QA │ ──► │ PROD │
                └────────┘     └────┘     └──────┘

                      ▲ 
                       \ 

                        ┌───────────────┐
 Builds:                │ release build │
                        └───────────────┘

                                ▲
                                │

                ┌────────┐ ┌─────────┐
 Branches:      │ master │ │ release │
                └────────┘ └─────────┘

การส่งเสริมจากสภาพแวดล้อมหนึ่งไปอีกสภาพแวดล้อมหนึ่งจะไม่ได้รับการจัดการในการควบคุมแหล่งอีกต่อไป ค่อนข้างเราเพียงแค่ใช้ไบนารีที่สร้างขึ้นแล้ว ("แพ็คเกจการปรับใช้") และวางลงในสภาพแวดล้อมใหม่

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

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

เราจะติดตามรหัสใดบ้างในแต่ละสภาพแวดล้อม

ตัวเลือกบางอย่างที่เรากำลังพิจารณา:

  • ใช้แท็ก Gitเพื่อติดตามการกระทำที่อยู่ในสภาพแวดล้อม
  • การฝังคอมไพล์คอมมิทที่ใช้โดยบิลด์ลงในแพ็คเกจการปรับใช้แต่ละแพ็กเกจ

คุณมีระบบ CI เช่นฮัดสันหรือเจนกินส์หรือไม่? มันสามารถผลักแท็กของสิ่งที่สร้างขึ้นกลับไปเป็นคอมไพล์ได้หรือไม่? (ฉันรู้ว่ามีปลั๊กอินสำหรับฮัดสันและเจนกินส์ที่สามารถ ... - ไม่แน่ใจเกี่ยวกับคนอื่น ๆ )

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

คำตอบ:


14

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

ในขณะที่นั่นคือคำตอบที่คุณกำลังมองหามันจะแก้ปัญหาเพียงครึ่งเดียว อีกอันคือ "เฮ้นี่คือการปรับใช้.[wje]arบนเซิร์ฟเวอร์มันมาจากไหน?" เรารู้ว่าคุณจะไม่เคยใช้แอปพลิเคชั่นรุ่นต่าง ๆ บน dev และ qa หรือ prod ขวา?

วิธีแก้ปัญหาของคำถามนั้นคือให้เซิร์ฟเวอร์บิลด์ใส่ข้อมูลลงในไฟล์ Manifest มาจากตัวอย่าง maven และ svn ที่ฉันมีต่อหน้าฉัน:

<manifestEntries>
    <Specification-Title>${project.name}</Specification-Title>
    <Specification-Version>${project.version}</Specification-Version>
    <Build-Number>${build.number}</Build-Number>
    <Build-Id>${build.id}</Build-Id>
    <Svn-Revison>${svn.revision}</Svn-Revison>
</manifestEntries>

maven-war-plugin archive แต่คุณสามารถค้นหาได้ในปลั๊กอินอื่น ๆ ด้วย จากนั้นในฮัดสันส่วนหนึ่งของคำขอร้องสร้าง maven คือ:

-Dbuild.number=${BUILD_NUMBER}
-Dsvn.revision=${SVN_REVISION}
-Dbuild.id=${BUILD_ID}

ซึ่งกำหนดเหล่านั้นกำหนดว่า maven หยิบขึ้นมา และจากนั้นเป็นเพียงเรื่องของการมองหาไฟล์ MANIFEST.MF ที่ถูกปรับใช้บนเซิร์ฟเวอร์เพื่อดูว่าเป็นเวอร์ชันใด

มีปลั๊กอินคอมไพล์ที่มีชุดของตัวแปรสภาพแวดล้อมที่คล้ายกัน ได้แก่ :

  • GIT_COMMIT - SHA ของกระแส
  • GIT_BRANCH - ชื่อของที่เก็บระยะไกล (ค่าเริ่มต้นไปยังจุดเริ่มต้น) ตามด้วยชื่อของสาขาที่ใช้อยู่ในปัจจุบันเช่น "Origin / master" หรือ "origin / foo"

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


3

แนวทางที่แตกต่างอย่างสิ้นเชิงคือการยกเลิกความคิดversionsอย่างสมบูรณ์ คุณมี "หนึ่งเวอร์ชัน" เท่านั้นซึ่งมีพฤติกรรมที่สามารถกำหนดค่าได้แตกต่างกัน ความแตกต่างเพียงอย่างเดียวคือคุณมี codebase ที่ใช้ร่วมกัน - แม้ในการผลิตคุณจะปรับใช้งานระหว่างดำเนินการ : แต่ไม่ได้เปิดใช้งาน

ความแตกต่างจะทำให้คุณสมบัติต่างกันที่เปิดใช้งานในผลิตภัณฑ์ของคุณแตกต่างกัน

de- / เปิดใช้งานจะทำผ่านสลับคุณลักษณะ

Upside: กระบวนการวางจำหน่ายทั้งหมดนั้นง่ายขึ้น: คุณมักจะส่งมอบซอฟต์แวร์เวอร์ชันรวมของคุณ คุณลักษณะทุกอย่างพร้อมใช้งานเสมอmasterทุกคุณลักษณะใช้ได้เสมอในไม่ต้องการสาขาเพิ่มเติม

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

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

บางทีมันอาจเหมาะกับคุณ


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

1
คำถามจะต้องถามที่แตกต่างกัน: เป็นข้อบกพร่องที่มีการกำหนดค่าพิเศษที่ทำซ้ำ "ตอนนี้" ถ้าใช่คุณสามารถแก้ไขได้ ถ้าไม่มี - ข้อผิดพลาดจะสำคัญหรือไม่ คุณมักจะผลักดันการทำงาน (และรหัสรวม)
Thomas Junk

-1

เราใช้ maven เพื่อใส่เวอร์ชันลงในไฟล์รายการ จากนั้นให้แอปพลิเคชันแสดงเวอร์ชันหากเป็นเว็บแอปพลิเคชันหรือมีจุดสิ้นสุด / เวอร์ชันสำหรับบริการบนเว็บ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.