เราเริ่มต้นจากนักพัฒนาหนึ่งรายและ repo svn หนึ่งตัวมีรหัสของเราทั้งหมด:
^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1
(ในเวลานี้เป็นการปรับปรุงครั้งใหญ่) หลังจากนี้มีโอกาสเติบโตขึ้นเล็กน้อยเราเริ่มมีปัญหากับการพึ่งพาแบบวนรอบการทดสอบช้าและปัญหาทั่วไปในการใช้รหัสอีกครั้ง (เนื่องจากชุดคุณลักษณะของเว็บไซต์ 1 มีอยู่ในโมดูลทั่วไป)
ต้องการทำให้โมดูลโค้ดเป็นโมดูลและคาดว่าเราจะย้ายไปที่คอมไพล์ในไม่ช้า (และเมื่ออ่านที่คอมไพล์ไม่ชอบ svn mega-repos) เราได้เปลี่ยนไปใช้โครงสร้างที่ละเอียดยิ่งขึ้น:
^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)
นี่เป็นแนวคิดที่ยอดเยี่ยม รหัสแบบแยกส่วนเพิ่มเติมชุดทดสอบที่เร็วกว่ามากง่ายต่อเอกสารและอื่น ๆ เราเปิดแหล่งที่มาของส่วนประกอบทั่วไปเพิ่มเติมและทำให้โมดูลทั้งหมดสามารถติดตั้งได้ (ใช้pip install -e .เพื่อติดตั้งในdevelopmentvirtualenv)
เราสร้าง^/srv/trunkพื้นที่เก็บข้อมูลที่มีโครงสร้างโฟลเดอร์ของสภาพแวดล้อมรันไทม์เช่น ^/srv/trunk/libสำหรับโมดูล/srv/trunk/srcสำหรับซากของ^/foo/trunk, ^/srv/trunk/wwwเว็บไซต์ ฯลฯ
และสุดท้าย (รับความคิดจากผู้ที่ฉันเคยทำงานมานานแล้ว [ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html] ) เราได้สร้าง "vcs-" ดึง "ไฟล์ข้อความที่แสดงรายการ repos ที่เกี่ยวข้องทั้งหมดและสถานที่ที่ควรเช็คเอาท์ในสภาพแวดล้อม dev และคำสั่งที่เกี่ยวข้องให้ทำ เช่นสาย vcs-fetc:
svn srv/lib/module-a ^/module-a/trunk
จะทำให้ทั้ง (ครั้งแรก)
cd /srv/lib && svn co ^/module-a/trunk module-a
หรือ (หลังจากนั้น)
cd /srv/lib/module-a && svn up
และคล้ายกันสำหรับ repos GitHub (ทั้งแพคเกจผู้ขายของเราเองและเปลี่ยนแปลง / ไม่เปลี่ยนแปลง)
เราใช้กระบวนการ vcs-fetch แบบเดียวกันสำหรับการสร้างสภาพแวดล้อมการผลิต แต่เราพบว่าเราไม่มีทางรู้ได้ว่าเวอร์ชันใดที่ใช้ในการทำงานในการผลิตหลังจากทำการ vcs-fetch
ด้วย mega-repo เราสามารถบันทึกหมายเลขการแก้ไขก่อนที่จะอัพเดทกระทุ้งจากลำตัวและการย้อนกลับนั้นง่ายsvn -r nnn up .มาก ด้วยรหัสทั้ง svn และ git (และหนึ่งโมดูลใน hg) - และ ~ 120 repos จึงไม่ชัดเจนว่าจะทำอย่างไร ..
ฉันอ่านhttp://12factor.net/วันนี้และปัจจัยแรกคือ "รหัสฐานเดียว" ดังนั้นฉันจึงสงสัยว่าถ้าฉันออกจากเส้นทางที่ถูกต้องที่นี่หรือไม่
หนึ่งความคิดที่ฉันมีคือการสร้างสคริปต์การปรับใช้ที่จะสร้าง pip-installable "การปรับใช้" - ล้อและ "มัด" พวกเขาด้วยกันในrequirements.txtไฟล์ จากนั้นการปรับใช้จะเกี่ยวข้องกับการสร้าง virtualenv ใหม่การติดตั้งไฟล์ requirements.txt ที่แสดงรายการล้อการปรับใช้และการสลับ virtualenv ที่ใช้งานอยู่ การย้อนกลับไปสู่ก่อนหน้าจะเป็นการเปลี่ยน virtualenv ย้อนกลับ (แต่ถ้าเราไม่ต้องการเก็บ virtualenv ไว้ตลอดไปมันจะไม่ยอมให้เราย้อนกลับไปที่จุดใดเวลาหนึ่ง - ในประสบการณ์ของฉันที่ไม่เคยต้องการ)
เมื่อมาถึงจุดนี้ฉันสงสัยว่าฉันกำลังเดินไปในทิศทางที่ผิดหรือถ้าฉันไม่ได้เดินไกลพอบนเส้นทางที่ถูกต้อง .. ? (ทุกสิ่งที่ฉันกำลังอ่านจะพูดถึง "แอปของคุณ" และฉันไม่รู้ว่าสิ่งนั้นแปลไปยังเว็บไซต์ 14 แห่งจากฐานรหัสเดียวกัน ... )