กระบวนการที่ Microsoft Office ย้ายจาก Source Depot ไปสู่ Git

• Microsoft Office ใช้ระบบจัดการซอร์สภายในอย่าง Source Depot มาเป็นเวลานาน ก่อนจะทำ การย้ายครั้งใหญ่ไปยัง Git เพื่อยกระดับประสบการณ์นักพัฒนาและนวัตกรรมทางเทคโนโลยี
• Source Depot มีข้อจำกัดด้านประสิทธิภาพจากความเป็น ระบบศูนย์กลาง, การสร้างบรাঞ্চที่ช้า, เวิร์กโฟลว์ที่ไม่สะดวก และการย้ายไป Git ต้องอาศัยงานต่อเนื่องหลายปีจากวิศวกรหลายร้อยคน
• ระหว่างการย้ายระบบ ทีมต้องฝ่าความท้าทายทางเทคนิคและระดับองค์กรครั้งใหญ่ เช่น การพัฒนาเทคโนโลยีใหม่อย่าง VFS for Git, การย้ายโครงสร้างพื้นฐานเดิมด้าน build/test และการรันสองระบบควบคู่กัน
• เพื่อให้การย้ายสำเร็จ มีการเน้นแนวทางแบบร่วมมือและยึดมนุษย์เป็นศูนย์กลาง เช่น ระบบการสื่อสารที่ขับเคลื่อนโดย "champion", ความโปร่งใสแบบกล้าตรงไปตรงมา, การอบรมเชิงปฏิบัติที่ใช้งานได้จริง และแผน rollback ทันที
• หลังการย้าย พบผลลัพธ์เชิงบวก เช่น เวลา onboarding ลดลง, ความชอบต่อ Git เพิ่มขึ้น (89%), และประสิทธิภาพการทำงานดีขึ้น พร้อมทิ้งบทเรียนสำคัญสำหรับการเปลี่ยนแปลงเทคโนโลยีขนาดใหญ่

---

จาก Source Depot สู่ Git: ประสบการณ์การย้ายระบบครั้งใหญ่ของ Microsoft Office

ความท้าทายใหม่ในการเร่งประสิทธิภาพของนักพัฒนา

• การยกระดับประสิทธิภาพของนักพัฒนาเป็นงานแบบ 'Multiplier work' ซึ่งยิ่งมีคุณค่ามากในองค์กรขนาดใหญ่
• โปรเจ็กต์ การย้าย Microsoft Office จาก Source Depot ไปยัง Git เป็นตัวอย่างสำคัญของเรื่องนี้
• งานนี้ไม่ใช่แค่การเปลี่ยนเครื่องมือ แต่เป็นโปรเจ็กต์ขนาดใหญ่ที่เกี่ยวข้องกับวิศวกรหลายร้อยคน ระบบที่ซับซ้อน และระยะเวลาดำเนินงานยาวนาน

Source Depot: เรื่องราวของระบบจัดการซอร์สในยุคนั้น

• ช่วงต้นทศวรรษ 2000 Microsoft ใช้งาน Source Depot ซึ่งเป็นระบบควบคุมเวอร์ชันภายในที่พัฒนาบนเทคโนโลยี Perforce
• Source Depot มีข้อจำกัดด้านประสิทธิภาพการทำงานจาก การสร้างบรাঞ্চที่ช้า, ความเป็นศูนย์กลาง, เวลาการ checkout โค้ดที่ยาวนาน รวมถึงวิธี merge ที่ไม่สะดวก (Reverse/Forward Integrate)
• โครงสร้างนี้ผูกติดอย่างแน่นแฟ้นกับระบบพัฒนาโดยรวมทั้งหมด (build, release, workflow) ทำให้ไม่สามารถเปลี่ยนแทนได้แบบง่าย ๆ
• การ เปลี่ยน Office ไปใช้ Git ต้องอาศัยเวลาหลายปีและความพยายามจากวิศวกรหลายร้อยคน

เริ่มจาก OneNote: จุดเริ่มต้นของการย้ายระบบ

• ภายในองค์กรวิศวกรรม Office มีการตัดสินใจย้ายไป Git ครั้งใหญ่จากทั้ง ต้นทุนการดูแลและแพตช์ Source Depot และความต้องการด้าน “เทคโนโลยีที่แข่งขันได้”
• ชุดผลิตภัณฑ์ Office มีตารางพัฒนาแตกต่างกันตามรอบการออกเวอร์ชัน (ทุกไม่กี่เดือน, รายครึ่งปี, รายเดือน, Insider) จึงจำเป็นต้อง ใช้งาน Source Depot และ Git ควบคู่กัน เป็นระยะเวลานาน
• ความสม่ำเสมอของการจัดการเวอร์ชันใน Office, การตรวจสอบ build และการย้ายโครงสร้างพื้นฐานการทดสอบแบบ legacy กลายเป็นโจทย์สำคัญที่ต้องจัดการ

ขนาดของ Office และกลยุทธ์การสื่อสาร

• ในเวลานั้น Office เป็นองค์กรขนาดใหญ่ที่มี วิศวกร 4,000 คน ทำงานร่วมกัน
• มีการแต่งตั้ง 'Developer Satisfaction Champion' ให้แต่ละทีม และวางโครงสร้างการรับฟังกับสื่อสารแบบ hub-spoke model เพื่อให้เกิด feedback และการประสานงานที่ราบรื่น
• ผู้เขียนทำหน้าที่เป็น champion ของ OneNote และรับบทบาทสำคัญในหน้างานของการย้ายระบบครั้งใหญ่ครั้งนี้

VFS for Git: ทลายข้อจำกัดของโค้ดเบสขนาดมหึมา

• ด้วยขนาดโค้ดที่ใหญ่จน git clone ครั้งเดียวต้องใช้มากกว่า 200GB ทีมจึงแก้ปัญหาด้วย Virtual File System for Git (VFS for Git) ที่พัฒนาร่วมกับ GitHub
• VFS for Git ใช้วิธีดึงมาเฉพาะไฟล์ที่มีการใช้งานจริง จึงช่วยก้าวข้ามข้อจำกัดของ Git แบบดั้งเดิม
• เป็นประสบการณ์ที่ได้ร่วมมือกับ Microsoft Windows เพื่อฝ่าข้อจำกัดของระบบจัดการเวอร์ชันระดับใหญ่ที่สุดกลุ่มหนึ่งในอุตสาหกรรม

แนวทางการย้ายระบบแบบเป็นขั้นตอน

ขั้นที่ 1: จักรวาลคู่ขนาน (Parallel Universe)

• มีการสร้างบริการ bridge ที่ซิงก์ Source Depot กับ Git แบบเรียลไทม์ และปรับปรุงซ้ำ ๆ เพื่อแก้ปัญหาความไม่สอดคล้องและความต่างของโมเดลทั้งสองระบบ (เช่น โครงสร้างบรাঞ্চ, changelist)
• กระบวนการ Office main/Private branch-sync-build ถูกทำงานผ่านระบบอัตโนมัติ 24/7
• หลังจากลองใหม่ถึงสามครั้ง จึงสร้างระบบคู่ขนานที่ทำงานได้อย่างเสถียรสำเร็จ

ขั้นที่ 2: การพิสูจน์ความเท่าเทียมกัน

• มีการรัน test suite ทั้งหมดซ้ำในทั้งสองระบบ เพื่อพิสูจน์ว่าผลลัพธ์ของ build เหมือนกันอย่างสมบูรณ์
• ความแตกต่างเล็ก ๆ เช่น รูปแบบการขึ้นบรรทัดใหม่, ตัวพิมพ์เล็ก/ใหญ่ และฟอร์แมตผลการทดสอบ ถูก debug และแก้ไขอยู่หลายเดือน
• เมื่อบรรลุผลแบบ 'Green across the board' (การทดสอบผ่านทั้งสองระบบ) ก็ถือว่าพร้อมเข้าสู่ช่วงเปลี่ยนผ่านจริง

แนวทางที่ยึดมนุษย์เป็นศูนย์กลาง

การสื่อสารหลายช่องทางและทำซ้ำ

• เพื่อให้ตารางเวลาของ วิศวกรมากกว่า 4,000 คนและหลายสิบทีม เดินไปพร้อมกัน มีการสร้างระบบสื่อสารอย่างเข้มข้นผ่าน champion ของแต่ละทีม
• ประกาศสำคัญจะสื่อสารซ้ำอย่างน้อย 3 ครั้ง (อีเมล, Teams, วิกิ, มีตติ้ง ฯลฯ) เพื่อลดความสับสนให้น้อยที่สุด
• เมื่อเกิดปัญหา จะเปิดเผยข้อมูลอย่าง รวดเร็วและโปร่งใส เพื่อสร้างความไว้วางใจ

การอบรมและการปรับตัวสู่ Git

• สำหรับวิศวกรที่คุ้นกับ Source Depot มานาน 10 ปี มีการเตรียม สภาพแวดล้อมการฝึกแบบลงมือทำจริง และ คู่มือคำสั่งสำหรับการเปลี่ยนผ่าน เพื่อให้เรียนรู้เป็นขั้นเป็นตอน
• มีการจัดทำคลังวิดีโอที่เน้นการใช้งานจริง เพื่อให้เกิด การเรียนรู้จากสถานการณ์จริง
• สิ่งนี้ไม่ได้มีไว้แค่ ลดความกังวลและเสริมทักษะ แต่ยังช่วยให้ผู้คนปรับตัวเข้ากับเวิร์กโฟลว์เดิมที่เปลี่ยนไปได้ด้วย

กลยุทธ์ rollback และมาตรการความปลอดภัย

• ในช่วงเปลี่ยนระบบจริง มีการมอบ 'ปุ่มแดง' ให้ Director เพื่อให้สามารถ rollback ได้ทันทีทุกเมื่อหากเกิดปัญหาร้ายแรง
• บันทึกบางส่วนจาก Source Depot เดิมถูกเก็บรักษาไว้เป็นเวลานาน เพื่อคงประวัติการพัฒนาเดิมไว้อย่างปลอดภัย

ผลลัพธ์และความสำเร็จหลัก

• หลังการย้าย พบ เวลา onboarding ลดลง 50%, ความชอบต่อ Git อยู่ที่ 89%, ประสิทธิภาพ build ดีขึ้น, ประสิทธิภาพ code review และการทำงานร่วมกันสูงขึ้น ซึ่งสะท้อน ผลลัพธ์ด้าน productivity ที่ดีขึ้น
• วิศวกรมองในแง่บวกต่อการได้ ทักษะที่สามารถนำไปใช้ต่อในอุตสาหกรรมได้
• ความสามารถในการให้พนักงานใหม่เริ่มงานได้ทันทีก็เพิ่มขึ้นเช่นกัน

บทเรียนสำคัญของการย้ายระบบขนาดใหญ่

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

บทสรุปและการประยุกต์ใช้ต่อไป

• การย้าย Office ไปสู่ Git เป็นโปรเจ็กต์ประวัติศาสตร์ที่เกิดขึ้นจากการเตรียมงานหลายปีและการลงมือจริงหลายเดือน
• ท้ายที่สุด มันกลายเป็น กรณีตัวอย่างของการขับเคลื่อนการเปลี่ยนแปลงระดับองค์กรได้สำเร็จ พร้อมรับประกันความต่อเนื่องของการทำงานสำหรับผู้คนหลายพันคน
• ในการเปลี่ยนแปลงขนาดใหญ่อื่น ๆ เช่น การย้ายขึ้นคลาวด์, การแยก monolithic architecture, หรือการอัปเกรด framework ก็สามารถนำแนวคิดเรื่อง การตรวจสอบแบบขนาน, การสื่อสารแบบทำซ้ำ, และการออกแบบ rollback อย่างรวดเร็ว ไปใช้ได้เช่นกัน
• แม้จะไม่ได้ลงรายละเอียดทางเทคนิคเพิ่มเติม (เช่น build infrastructure, ประเด็น offline/contract) แต่บทเรียนที่สำคัญที่สุดยังคงเป็นแนวทางเชิงกลยุทธ์และเชิงองค์กรต่อการเปลี่ยนแปลงเทคโนโลยีขนาดใหญ่

[ndrgrd]

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

[rtyu1120]

แม้ภายใน Microsoft เองก็น่าจะเป็นการเปลี่ยนแปลงครั้งใหญ่ แต่ผลดีอีกอย่างคือฟีเจอร์อย่าง partial clone, sparse checkout รวมถึงเครื่องมืออย่าง Scalar ก็ถูกเปิดเผยออกมาสู่ภายนอกจนสามารถนำไปใช้งานได้ด้วย ซึ่งนับว่าเป็นผลกระทบเชิงบวกเหมือนกันครับ 555

[GN⁺]

ความคิดเห็นบน Hacker News

• รู้สึกว่าอ่านเรื่องเล่าเก่า ๆ ที่ถูกนำมาเล่าใหม่ให้น่าสนใจแบบนี้ทีไรก็เพลินเสมอ ผู้แสดงความเห็นชี้ว่าในบทความต้นฉบับมีการพูดถึงว่า “ใช้เวลาหลายชั่วโมงในการดึงรีโพ Office ทั้งหมดมา” แต่แทบไม่ได้พูดตรง ๆ เลยว่าในโลกของ git นั้น หากไม่มีระบบไฟล์แบบใหม่อย่าง VFS งานลักษณะนี้แทบเป็นไปไม่ได้เลย ใน Perforce ผู้ใช้สามารถ checkout เฉพาะส่วนที่ต้องการได้ จึงคาดว่าผู้ใช้ Source Depot ส่วนใหญ่ก็คงไม่ได้ดึงทั้งแอป Office ทุกครั้ง แต่ดึงเฉพาะส่วนที่จำเป็น VFS ช่วยลดช่องว่างนี้โดยทำให้ git ดาวน์โหลดเฉพาะ object ที่ต้องใช้ Perforce/Source Depot เป็น VCS แบบรวมศูนย์ที่ยอดเยี่ยมมากในยุคนั้น แต่ตอนนี้ก็รู้สึกได้ว่ายุคสมัยเปลี่ยนไปแล้ว
  • มีคำอธิบายว่าฝั่ง Perforce เองก็มีบริษัทที่สร้างเทคโนโลยีของตัวเองให้ดึงไฟล์เฉพาะตอนที่ต้องใช้ได้ คล้ายกับ VFS เรื่องนี้สำคัญมากโดยเฉพาะในงานพัฒนาเกมที่ต้องเก็บทั้งไฟล์ข้อความและ asset ต้นฉบับแบบไบนารีขนาดใหญ่ คิดว่าเทคโนโลยีนี้มีรากเดียวกับที่โปรแกรม remote drive ที่มากับ Windows ใช้อยู่ ส่วนตัวแล้วยังอยากได้ VCS แบบอิงเซิร์ฟเวอร์ที่เก็บซอร์สทั้งบริษัทไว้ แต่ไม่จำเป็นต้องคัดลอกประวัติทั้งหมดลงเครื่อง local ถึงอย่างนั้น git ก็ใช้งานได้ดีพอสำหรับการร่วมงานแบบชั่วคราวระหว่างหลายอุปกรณ์ จึงยังไม่รู้สึกจำเป็นต้องตั้งทั้งเซิร์ฟเวอร์กลางและ CI/CD pipeline ชอบ workflow ต่าง ๆ ของ git มาก เช่น stash, stage ระดับ hunk และ interactive rebase
  • บริษัทเรายังใช้ perforce อยู่เลย น่าเสียดายที่ตอนนี้แทบไม่มีใครชอบ perforce แล้ว เคยเห็นกับตาว่าพอบอกพนักงานใหม่ว่า “เราไม่ได้ใช้ git” แววตาพวกเขาก็ดับลงทันที
  • VFS ไม่ได้มาแทน Perforce ได้ทั้งหมด มีการย้ำว่าบริษัทเกมระดับ AAA ส่วนใหญ่ก็ยังใช้ Perforce อยู่ เพราะต้องล็อกไฟล์ asset เพื่อป้องกันไม่ให้สองคนแก้พร้อมกันแล้ว merge ไม่ได้ และสิ่งนี้จำเป็นมากเพื่อลดเวลาสูญเปล่าจากการต้องทิ้งผลงานของศิลปินคนหนึ่ง
  • พูดตามตรงว่ายังสงสัยว่าทำไม git ถึงยังไม่มีฟีเจอร์ให้ checkout แบบเลือกเฉพาะบางส่วนของ tree ในรีโพได้จริง ๆ คิดว่าแค่มีบริการตัวกลางที่เข้าใจพวก object file ก็น่าจะขยายให้ทำได้ไม่ยาก
• มีประสบการณ์ตอนฝึกงานที่ Microsoft ในปี 2016 ตอนสร้างตัวรีวิวโค้ดอัตโนมัติที่รองรับ Source Depot ทั้งที่ไม่รู้ด้วยซ้ำว่า Source Depot คืออะไร และใช้เวลาไปเกือบสัปดาห์กับฟีเจอร์นี้ (https://austinhenley.com/blog/featurestheywanted.html) ตอนนั้นก็ยังมีนักพัฒนาจำนวนมากใช้ Source Depot อยู่ เลยสงสัยว่าตอนนี้ย้ายไป git กันหมดแล้วหรือยัง
  • คิดถึง CodeFlow ทุกวัน เป็นเครื่องมือที่ยอดเยี่ยมจริง ๆ
  • มีการบอกว่ายังมีหลายพื้นที่ที่ Source Depot ถูกใช้งานอย่างจริงจังอยู่ คำสั่งและการตั้งค่าสภาพแวดล้อมของ Source Depot ทำให้รู้สึกกดดันอยู่เสมอ
  • ตอนนี้งานประจำวันส่วนใหญ่ย้ายไปทำบน git แล้ว
• ในฐานะคนที่เคยใช้ vss (Visual SourceSafe) เองในยุค 90 รู้สึกแปลกใจที่บทความนี้ไม่พูดถึงมันเลย Visual SourceSafe เป็นโปรโตคอลจัดการเวอร์ชันซอร์สที่ Microsoft ทำเอง ซึ่งต่างจาก Source Depot ที่เป็นของ Perforce แล้วนำมาใช้ภายใต้ไลเซนส์
  • VSS (Visual SourceSafe) เป็นผลิตภัณฑ์ที่ได้มาจากการเข้าซื้อ One Tree Software ที่เมือง Raleigh แล้วเปลี่ยนชื่อผลิตภัณฑ์จาก “SourceSafe” เป็น “Visual SourceSafe” เพื่อจับ bundle กับ Visual C, Visual Basic และตัวอื่น ๆ ก่อนหน้านั้น Microsoft เคยขายผลิตภัณฑ์จัดการเวอร์ชันชื่อ “Microsoft Delta” ซึ่งราคาแพง คุณภาพต่ำ และไม่รองรับ NT เลย คนหนึ่งที่เข้ามาหลังการซื้อ One Tree คือ Brian Harry ซึ่งต่อมาเป็นผู้นำ Team Foundation Version Control (TFS) โดยใช้ SQL Server เป็นที่เก็บข้อมูล ทำให้จัดการง่ายและเชื่อถือได้มากกว่า VSS อย่างมาก ดูเหมือนตอนนี้ Brian Harry จะเกษียณแล้ว และบล็อกก็ไม่ได้อัปเดตอีกแล้ว สิ่งหนึ่งที่ยังจำได้จากตอนใช้ VSS คือมันจัดการ network file locking ผ่าน SMB ทำให้เปราะบางต่อปัญหาเครือข่ายมาก และรีโพก็พังบ่อยมาก ถึงขั้นต้องตั้ง batch job ให้ซ่อมทุกคืนตอนตีสอง เพื่อให้ตอนเช้าใช้งานได้
  • จากประสบการณ์ใช้ VSS ในยุค 90 มันแทบเป็นฝันร้ายเมื่อใช้ทำงานเป็นทีม และเท่าที่รู้ Microsoft เองก็แทบไม่ได้ใช้ภายในจริงจัง
  • ตอนพัฒนาคนเดียวในยุค 90 เคยใช้ VSS และตอนนั้นมันเหมือนโลกใหม่เลย ตอนเรียนบัณฑิตศึกษาก็เคยเจอ VCS อื่น ๆ เช่น RCS, CVS ฯลฯ จำได้ว่าตอนเข้าทำงานที่ Microsoft ในปี 2004 มีคนอธิบายให้ฟังว่า VSS ไม่ปลอดภัยและพังง่าย ไม่รู้ว่าเป็นเรื่องจริงแค่ไหน แต่ในบริษัทมันไม่ใช่ตัวเลือกเลยอยู่แล้ว
• เคยเป็นสมาชิกทีมตอน Microsoft ย้ายจาก XNS ไป TCP/IP งานนี้จริง ๆ ไม่ได้ซับซ้อนอย่างที่คิด แต่ก็ได้บทเรียนคล้ายกัน ส่วนการย้ายจาก MSMAIL ไป Exchange นั้นโหดมากจริง ๆ
  • เคยเห็นกรอบป้ายทะเบียนที่เขียนว่า “Exchange: The Most Feared and Loathed Team in Microsoft” เลยสงสัยว่านี่เกี่ยวกับประสบการณ์ยุคนั้นหรือเปล่า เรื่องมันราว 20 ปีก่อนแล้ว เลยจำถ้อยคำเป๊ะ ๆ ไม่ได้
• ประโยค “Authenticity mattered more than production value” โดนใจมาก ในฐานะอดีตพนักงาน Microsoft ที่เคยทำงานในสายผลิตภัณฑ์ขนาดเล็กซึ่งเพิ่งเริ่มย้ายจาก Source Depot ไป Git ตอนใกล้จะลาออกในปี 2015 เข้าใจเต็มที่ว่าต้องใช้ความพยายามมากแค่ไหน เป็นความสำเร็จที่ยอดเยี่ยมจริง ๆ
  • ฉันเองก็ยังไม่อยากเชื่อว่าได้ผ่านกระบวนการทั้งหมดนี้มาจริง ๆ ขอบคุณมาก
• มองจากสถานการณ์ที่ Microsoft เผชิญในช่วงต้นยุค 2000 ตอนนั้น Windows ซับซ้อนขึ้นมหาศาลและมีโค้ดหลายล้านบรรทัดที่ต้องจัดการเวอร์ชัน ขณะที่ git ยังไม่เกิด และ SVN ก็เพิ่งเริ่มเติบโต เลยสงสัยว่า Microsoft เคยพิจารณาผลิตภัณฑ์เชิงพาณิชย์อย่าง BitKeeper ซึ่งพัฒนาในปี 1998 และเปิดตัวในปี 2000 อย่างจริงจังหรือไม่ เดาว่าตอนนั้นระบบรวมศูนย์อย่าง Perforce น่าจะเป็นกระแสหลัก และระบบกระจายศูนย์อย่าง BitKeeper อาจดูแปลกใหม่เกินไปหรือยังมีกรณีใช้งานที่พิสูจน์แล้วไม่มากพอ
  • ตอนนั้นก็มี VSS (Visual SourceSafe) และหลังจากนั้นก็มี TFVC
• อยากขอบคุณบรรดา dev lead ที่ช่วยไขปริศนา Source Depot ให้กับวิศวกรมือใหม่อย่างฉัน พอเข้าใจโครงสร้างของ Source Depot อย่างถูกต้องแล้วเหมือนตาสว่างเลย ฉันพึ่งพาแค่ WinCE กับ IE เลย clone ใช้เวลาเพียง 20 นาที ไม่ได้กินเวลาหลายวัน ถือว่าโชคดีมาก จำชื่อคนที่ช่วยไม่ได้แล้ว แต่ท่าทีที่พยายามช่วยให้พนักงานใหม่เริ่มงานได้ง่ายขึ้นนั้น ฉันยังสืบต่อและทำแบบเดียวกันในทีมทุกวันนี้
• คนส่วนใหญ่มักจำการนำ git มาใช้ว่าเป็นชัยชนะทางเทคนิค แต่จริง ๆ แล้วนวัตกรรมที่แท้จริงคือการที่นักพัฒนาแต่ละคนควบคุม workflow ของตัวเองได้ ไม่ต้องรอหน้าต่าง sync อีกต่อไป ไม่ต้องขอหัวหน้าเพื่อเข้าถึง branch อีกแล้ว ตอนนี้ทุกคนทำงานได้เร็วขึ้นอย่างอิสระโดยไม่ชนกัน ความเปลี่ยนแปลงนี้ส่งผลต่อบรรยากาศมากกว่าต่อ dashboard วัดประสิทธิภาพเสียอีก git ไม่ได้เปลี่ยนแค่เครื่องมือ แต่เปลี่ยนความเชื่อมั่นที่มีต่อ development loop ด้วย
• สงสัยว่า Microsoft เลิกพึ่ง Visual SourceSafe ภายในจริง ๆ เมื่อไหร่ คิดว่าน่าจะเลิกผลิตให้เร็วกว่านั้นเพื่ออย่างน้อยจะได้ไม่ปล่อยให้คนนอกยังใช้งานมันต่อไป
  • คิดว่าทีมส่วนใหญ่น่าจะไม่ได้ใช้ VSS กันจริง ตอนทำงานที่ Microsoft ทีมของฉันใช้ Source Depot เคยใช้ TFS ด้วยแต่ไม่ค่อยชอบ ถึงอย่างนั้นพอได้ใช้ Source Depot แล้วกลับคิดถึง TFS ขึ้นมาเสียอย่างนั้น
  • สงสัยว่า Microsoft ใช้ VSS ภายในกับงานหลักจริงหรือไม่ ถ้าใช้จริงก็คงไม่น่าปล่อยผลิตภัณฑ์ออกมาในสภาพหละหลวมแบบนั้น TFS ก็เป็นประสบการณ์ที่เข้าใจได้ยาก ไม่ว่าจะภายในหรือภายนอกก็ไม่ค่อยดี
  • น่าจะราวปี 2000 เท่าที่ฉันรู้โปรเจกต์เดียวที่ใช้คือ .NET และถึงอย่างนั้นก็ย้ายไป Source Depot แล้ว
  • มีคนตอบว่าไม่เคยรู้ด้วยซ้ำว่ามี Microsoft SourceSafe อยู่
• ยังไม่ค่อยเข้าใจประโยคที่บอกว่า OneNote shallow clone มีขนาด 200GB
  • มีคำอธิบายว่าจริง ๆ ไม่ใช่ OneNote แต่เป็น shallow clone ของ office ทั้งชุด
  • คาดว่าน่าจะมีวิดีโอหรือไบนารีขนาดใหญ่รวมอยู่ด้วย