เกริ่นนำ
ผมได้มีโอกาศทำงานบริษัทญี่ปุ่นกับทีมญี่ปุ่น โปรเจ็คที่ทำอยู่อายุกว่า 10 ปีแล้ว และตัวโปรเจ็คเองก็ใช้ svn เป็น source control และก็ยังใช้มาเรื่อยๆ ซึ่งตัวโปรเจ็คก็มีขนาดที่ใหญ่พอสมควรซึ่งใหญ่จนบ่นว่าช้าได้ก็คงต้องบอกละว่าเป็นเกม เพราะเก็บทั้ง code และ resource หากใครเคยใช้ svn กับโปรเจ็คใหญ่ๆจะรู้ว่ามันช้ามาก เพราะมันต้องดึงข้อมูลมาใหม่ทุกครั้งที่เรียกใช้คำสั่งใน svn แตกต่างจาก git ที่ clone โปรเจ็คลงเครื่องเราก่อนที่จะ checkout ได้
ซึ่งทางทีมญี่ปุ่นเองเขาก็ host เจ้า svn repositories บนเครื่อง server ในออฟิศเองนั่นแหละ ต่อมาทางทีมไทยก็มีเข้าไปศึกษาและเพิ่ม feature ในเกมบ้าง ซึ่งเวลาทำงานก็จะช้าพอสมควร (ไม่ได้อยู่ในวง local ด้วยนี่นา)
แล้วพอมาวันหนึ่ง ทีมทางญี่ปุ่นก็เหมือนจะต้องไปพัฒนาโปรเจ็คตัวใหม่ และฝากฝั่งการเมนเทนและพัฒนาไว้กับทีมไทย…
ทางญี่ปุ่นส่ง Hard Disk ที่ก็อปปี้ SVN repositories มาให้ เอามาให้เรา host เองในออฟิศเพื่อแก้ปัญหาเรื่องความช้าในการ commit งานหรือ checkout งานต่างๆใน SVN
ซึ่งมันก็เร็วขึ้นแหละครับ แต่มันก็ยังแบบว่าช้ากว่าการที่เราใช้ Git อยู่พอสมควร
ถึงเวลาที่จะต้องสังคายนา Source Control
ไม่ไหวละ มันช้าาาาาาาาา ถึงช้ามาาาาาากกกก เราก็มีการพูดคุยกันว่าย้ายมาใช้ Git กันเถอะ มันเร็วกว่าเยอะเลยนะ ทางเบื่องบนก็เห็นว่าไม่ดีมั้ง history ของ svn ที่ทำกว่า 10 ปีมันจะหายไป ถ้าจะมาตัดขึ้น Git
เราก็ทำการค้นคว้าเล็กๆพบว่า Git เองมีคำสั่ง built-in ในการแปลง SVN ให้มาเป็น Git
เอาล่ะ ฟังดูดีทีเดียว
ปัญหาต่อไป… เอ้าใครจะทำดี? นั่งๆคุยกันอยู่นี่ก็เป็น Programmer ที่เน้นเขียน code ไม่ใช่บริษัทใหญ่ๆ ที่มีตำแหน่ง DevOps หรือ System Admin อะไรแบบนั้น
แน่นอนว่าการที่ผมได้มาเขียน post นี้หมายความว่าผมได้เป็นคนทำแน่ๆ
ก่อนที่จะไปถึงขั้นตอนแปลง SVN มาเป็น Git มาพูดถึงขั้นตอนเลือก Git repositories manager software ที่จะเอามาใช้ก่อนละกัน
ตอนที่ทำการเปรียบเทียบระบบต่างๆ ตัวที่เข้ารอบมีอยู่ 2 ตัว นั่นคือ
ซึ่งทั้งสองมีเวอร์ชั่น Community Edition (CE) สำหรับการใช้นำมา host เองฟรีทั้งคู่แต่โดนจำกัดบางความสามารถ
และที่สำคัญรองรับการใช้งาน Git – Large File Storage (LFS) ทั้งคู่
สุดท้ายตัวที่เลือกมาก็คือ GitLab ซึ่งเอกสารอะไรก็เยอะกว่าพอสมควร เป็นที่นิยมรองลงมาจาก GitHub เลยละมั้ง…
ปัญหาต่อไปของ Windows User
GitLab หรือ software ประเภทเดียว ส่วนใหญ่จะติดตั้งได้บนเฉพาะ Unix ซึ่งผมไม่เคยใช้มาก่อนเลย…
เราเลือกใช้ VirtualBox เป็น Virtual Machine Software ครับ ลงและใช้งานมันบน Windows Server ที่ใช้นี่แหละ
และเราเลือก Ubuntu Server พอลงเสร็จมันก็มีมาแต่ Terminal ง่อยๆ(ครับ ผมรู้ครับว่าบางคนอ่านแล้วบอกว่า ง่อยอะไร นี่แหละสุดยอดของความ Powerful แล้ว) ไม่มี UI อะไรมาให้ใช้งานเลย
ก็ลองเล่นกับคำสั่งทำความคุ้นเคยกับโครงสร้างและคำสั่งต่างๆบน Ubuntu อยู่พักนึ่งก่อนจะลง GitLab ต้องบอกเลยว่า แทบจะจับจอคอมทุ่มเพราะบางทีมันหงุดหงิดกับความไม่รู้เลยความไม่เคยชินกับการใช้แต่ Command Line บน Unix เลยจริง
พอเสร็จแล้ว อู้วววว ระบบสุดยอด และ UI มันสวยงามอะไรขนาดนนี้
ก็ลองสร้างโปรเจ็คทดสอบการใช้งานทั้งแบบปกติและแบบใช้ LFS
เอาว่ะ ผ่านๆๆ เตรียมขั้นตอนต่อไป
ถึงเวลาแปลง SVN ให้มาเป็น Git
พร้อมแล้ว Enter !!!
git svn clone --stdlayout --no-metadata -A ~/authors.txt http://svn/repo/bigproject
นั่งรอมันไป 2 วันกว่าๆครับ กว่ามันจะแปลงเสร็จ แล้วขนาด Git repository ที่ได้มานั่นใหญ่ถึง 30GB กันเลยทีเดียว รวมกับตัวโปรเจ็คด้วยแล้ว 45GB+ โอ้วว
เสร็จแล้วก็ใส่ .gitattributes ที่เตรียมเอาไว้เพื่อบอกว่าจะให้พวก Resources (png, fbx, ogg, อื่นๆ) ไปเก็บแยกเป็น LFS นะ
เสร็จแล้วก็ Push สิ รออะไร
หลังจากที่ Push ไปประมาณ 3 ชั่วโมงกว่าๆ ใน Command Line โชว์ว่า “Bad Gateway”
ไปจ้องในจอ Terminal ในฝั่งเซิร์ฟเวอร์มันบอกว่า RAM หมดขอตัดโปรเซสนี้ทิ้งนะ
อะไม่เป็นไรเพิ่ม RAM ให้อีกเป็น 8 GB ก็ยังไม่พอ เพิ่มไป 20GB ถึงจะพอ
เอาล่ะ ในที่สุดก็ได้แล้ว แต่ทว่า…
ทำการบ้านมาไม่ดีพอ
ลอง Clone ดูปรากฎว่า มันก็มาทั้งยวงแบบเดิมไม่ได้ แยกเป็น LFS แต่อย่างใด
เหตุผลก็คือมันต้องใช้อีกคำสั่งแปลงจากการเก็บแบบปกติให้มาเป็นเก็บแบบ LFS ก่อน จะมาใส่ลงใน .gitattributes แบบการสร้างโปรเจ็คครั้งแรกเลยไม่ได้
git lfs migrate import --include="*.png, *.fbx, *.ogg" --include-ref=refs/heads/master --include-ref=refs/heads/branch-1
ขั้นตอนนี้กินเวลาไปอีก… 1 วัน
บทสรุป
ในที่สุดก็เสร็จละ พร้อม Push จริงๆสักที และคราวนี้ RAM Usage ของเครื่องเซิร์ฟเวอร์พีคไปที่แค่ประมาณ 8GB กว่าๆเท่านั้น เป็นเพราะพวก LFS objects นั้นถูกอัพโหลดขึ้นไปเก็บแยกจาก Git Repository โดยสิ้นเชิง และไม่ต้องมานั่งบีบอัดไฟล์รวมไปกับ Git Objects
ตัว .git เหลือแค่ 18GB ที่เหลือเป็น LFS Objects อีกกว่า 50GB…
แต่ในทางใช้งานจริงเครื่องที่จะ clone ก็จะได้ไฟล์มาทั้งหมด 38GB (จาก 45GB) และที่สำคัญ เร็วมากกกกกกกกกกกกกก ใช้เวลา clone แค่ 30-35 นาที เท่านั้น!!!
เสริมความมั่นใจในการเก็บข้อมูลโดยการอัพโหลดไปเก็บที่อื่นด้วย
ตัว GitLab เองมีความสามารถในการส่งข้อมูลไปเก็บที่ Cloud Storage ด้วยในตัว แต่ว่าเรามีแต่ Dropbox ซึ่ง GitLab ไม่ซัพพอร์ทโดยตรง ไม่เป็นไรไม่ใช่ปัญหาอะไรมาก เราก็ใช้คำสั่งก็อปปี้ไปวางเองดื้อๆเลย ไม่มีอะไรซับซ้อนมาก
ทั้งหมดนี้กินเวลาทั้งทำการเรียนรู้และติดตั้งใช้งานเสียเวลาไป 1 อาทิตย์เต็ม