การควบคุมเวอร์ชันของเว็บไซต์: ไฟล์ dev / production front-end

ฉันพยายามคิดถึงวิธีที่ดีกว่าในการควบคุมเวอร์ชันโครงการเว็บไซต์ของเรา โปรดทราบว่าฉันเป็นเพียงส่วนหนึ่งของส่วนหน้าดังนั้นฉันจึงไม่มีความรู้ที่ลึกซึ้งเกี่ยวกับ VCS

เวิร์กโฟลว์กำลังเปลี่ยนแปลงและพฤติกรรมการควบคุมเวอร์ชันที่ผ่านมาล้าสมัย ปัญหาหลักคือมี 2 อาร์เรย์ของไฟล์ส่วนหน้าสำหรับแต่ละเว็บไซต์

สภาพแวดล้อม dev (ไฟล์น้อยลง js ที่ไม่บีบอัดรูปภาพ ฯลฯ ) สภาวะแวดล้อมบิลด์ "gulpified" (ทุกสิ่งถูกบีบอัดและไม่สามารถอ่านได้โดยมนุษย์)

แต่คุณไม่สามารถขายเว็บไซต์ด้วยไฟล์ต้นฉบับได้ มันรู้สึกไม่ถูกต้อง

มีวิธีแก้ปัญหาของการมี 2 repos: หนึ่งบิลด์หนึ่ง dev กับอึกส่งไฟล์ dev เพื่อสร้างไดเรกทอรี แต่มันเป็นเรื่องยุ่งยากที่จะรักษาด้วย บริษัท เล็ก ๆ ฉันไม่คิดว่ามันเยี่ยมขนาดนั้น มันสร้าง repos มากมายและผู้คนต้องจัดการกับ repos หลาย ๆ ครั้งบางครั้งถึงกับ repo svn เพียงตัวเดียวปัญหาก็เกิดขึ้น

ดังนั้นยังมีวิธีแก้ปัญหาของการมี 1 repo: ไฟล์ต้นฉบับและไฟล์ prod ใน svn เดียวกัน แต่ก็จำเป็นต้องลบไฟล์ต้นฉบับเมื่อเว็บไซต์ไปจากเซิร์ฟเวอร์ dev ในตัวเครื่องไปยังเซิร์ฟเวอร์ที่ใช้งานจริง (ดังนั้นจึงมีไฟล์ต่าง ๆ ในที่เก็บข้อมูลเดียว จากสิ่งที่ฉันได้ยินมันไม่ดี

วิธีที่ถูกต้องในการจัดการเวิร์กโฟลว์ front-end อึกเกี่ยวกับระบบการควบคุมเวอร์ชันคืออะไร?

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

ดังนั้นหากคุณมีกระบวนการอัตโนมัติในการสร้างไฟล์การผลิตจากไฟล์แหล่ง dev ของคุณคุณจะต้องใส่ไฟล์ dev ลงในการควบคุมแหล่งที่มา (พร้อมกับสคริปต์สำหรับการสร้างไฟล์การผลิต) ถ้าไม่สร้างกระบวนการดังกล่าว ตรวจสอบให้แน่ใจว่าไม่มีใครที่จะต้องยุ่งเกี่ยวกับไฟล์การผลิตด้วยตนเองหลังจากที่พวกเขาถูกสร้างขึ้นจากแหล่งที่มา หากคุณต้องการปรับใช้ "โดยตรง" จาก VCS ของคุณตรวจสอบให้แน่ใจว่าคุณมีสคริปต์การปรับใช้ที่ดึงไฟล์ต้นฉบับ dev ออกจากการควบคุมแหล่งที่มา "gulpification" และโอนไฟล์ผลลัพธ์ไปยังการผลิตในขั้นตอนเดียว

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

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