นักพัฒนาถกเถียงความท้าทายในการย้ายจาก GitHub ขณะที่ Codeberg ได้รับความสนใจเป็นทางเลือก

ชุมชนนักพัฒนากำลังหารือกันอย่างกระตือรือร้นเกี่ยวกับความเป็นจริงในทางปฏิบัติของการย้ายออกจาก GitHub หลังจากมีคู่มือรายละเอียดเกี่ยวกับการเปลี่ยนไปใช้ Codeberg แม้ว่ากระบวนการย้ายจะดูตรงไปตรงมา แต่ความท้าทายด้านเทคนิคและโครงสร้างพื้นฐานหลายประการกำลังสร้างอุปสรรคสำคัญให้กับโปรเจกต์จำนวนมาก

ภาพรวมของกระบวนการย้ายข้อมูล

ขั้นตอนการย้ายจาก GitHub ไป Codeberg :

• สร้าง personal access token ของ GitHub พร้อมสิทธิ์การเข้าถึง repository
• ตั้งค่าบัญชี Codeberg และเริ่มการย้าย repository
• เก็บ repository เดิมใน GitHub เข้าคลัง
• อัปเดต Git remotes ในเครื่องให้ชี้ไปที่ Codeberg
• กำหนดค่า SSH keys (ต้องใช้ RSA 4096 หรือ ed25519 ไม่ใช่ RSA 2048)

การสนับสนุน Actions ที่จำกัดสร้างอุปสรรคใหญ่ในการย้าย

หนึ่งในอุปสรรคสำคัญที่สุดที่นักพัฒนาต้องเผชิญเมื่อพิจารณาทางเลือกอื่นจาก GitHub คือการสนับสนุน Actions ที่จำกัดในแพลตฟอร์มอย่าง Codeberg ซึ่งแตกต่างจากโครงสร้างพื้นฐาน CI/CD ที่แข็งแกร่งของ GitHub โดย Codeberg ต้องการให้ผู้ใช้จัดหา runners ของตัวเองสำหรับ automated workflows ข้อจำกัดนี้ส่งผลกระทบเป็นพิเศษต่อโปรเจกต์ open source ที่พึ่งพา automated testing, การสร้างเอกสาร และ deployment pipelines อย่างมาก

ความรับผิดชอบด้านโครงสร้างพื้นฐานที่มาพร้อมกับ self-managed runners กำลังทำให้นักพัฒนาจำนวนมากที่ไม่ต้องการจัดการโครงสร้างพื้นฐานเซิร์ฟเวอร์เพิ่มเติมรู้สึกท้อถอย สำหรับโปรเจกต์ที่มีกระบวนการ build ที่ซับซ้อนหรือ automated workflows หลายตัว สิ่งนี้แสดงถึงภาระด้านการดำเนินงานที่มากมายซึ่งบริการ Actions ที่จัดการโดย GitHub ช่วยขจัดไป

การเปรียบเทียบแพลตฟอร์ม

ความแตกต่างหลักระหว่าง GitHub และ Codeberg:

• การรองรับ Actions: GitHub มี managed runners ในขณะที่ Codeberg ต้องใช้ self-hosted runners
• การโฮสต์ Pages: GitHub รองรับการ deploy แบบ branch/Actions ในขณะที่ Codeberg ต้องการให้เนื้อหาอยู่ที่ root ของ repository
• โครงสร้างพื้นฐาน: GitHub เป็นแบบ fully managed ในขณะที่ Codeberg/self-hosted ต้องการการบำรุงรักษามากกว่า
• การฝึกอบรม AI: GitHub ฝึกโมเดลจากโค้ดสาธารณะ ในขณะที่ Codeberg ดำเนินงานโดยองค์กรไม่แสวงหาผลกำไรของเยอรมันที่มีนโยบายแตกต่างกัน

ชุมชนตั้งคำถามเกี่ยวกับแรงจูงใจในการย้าย

การหารือเรื่องการย้ายได้เผยให้เห็นมุมมองที่หลากหลายเกี่ยวกับเหตุผลพื้นฐานในการออกจาก GitHub นักพัฒนาบางคนตั้งคำถามว่าความกังวลที่ระบุไว้เกี่ยวกับแนวปฏิบัติด้านความปลอดภัยของ Microsoft และการฝึกอบรม AI บน public code repositories นั้นสมควรกับความพยายามในการย้ายหรือไม่ โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่าการฝึกโค้ดโดยโมเดล AI เกิดขึ้นทั่วอินเทอร์เน็ตไม่ว่าจะใช้แพลตฟอร์มโฮสติ้งใด

อย่างไรก็ตาม คนอื่นๆ ชี้ไปที่การพัฒนาล่าสุดที่เป็นรูปธรรมมากกว่า รวมถึงการผลักดันของ GitHub สำหรับการรวม AI และเหตุการณ์เฉพาะที่เกี่ยวข้องกับข้อมูลใน private repository การถกเถียงนี้เน้นให้เห็นว่านักพัฒนาแต่ละคนชั่งน้ำหนักความกังวลด้านจริยธรรมกับความสะดวกในทางปฏิบัติอย่างไร

โซลูชันโฮสติ้งทางเลือกเริ่มปรากฏ

การสนทนานี้ยังได้ให้ความสนใจกับทางเลือกอื่นของ GitHub นอกเหนือจาก Codeberg โซลูชันการโฮสต์ด้วยตนเองอย่าง Gitea กำลังได้รับการยอมรับในด้านความเรียบง่ายและความสมบูรณ์ของฟีเจอร์ Gitea เสนอการติดตั้งแบบ single binary ที่ต้องการการกำหนดค่าน้อยที่สุด ทำให้น่าสนใจสำหรับองค์กรที่ต้องการควบคุม code repositories ของตนเองอย่างเต็มที่

สำหรับโซลูชันการโฮสต์ด้วยตนเอง ผมแนะนำ gitea: มันเป็น single go binary ที่ไม่ต้องการการติดตั้งเกือบเลย ต้องการเพียงไฟล์ config เท่านั้น มันเร็วมาก การอัปเดตทำงานได้ดี และมีฟีเจอร์ทั้งหมดของ GitHub ที่คุณชื่นชอบ

นักพัฒนาบางคนยังกำลังสำรวจโซลูชันที่เป็นการทดลองมากกว่าอย่าง Radicle แม้ว่าประสบการณ์ของชุมชนกับแพลตฟอร์มใหม่เหล่านี้สำหรับโปรเจกต์ production ยังคงมีจำกัด

แพลตฟอร์มทางเลือกที่กล่าวถึง

ตัวเลือกการโฮสต์เอง:

• Gitea: ไฟล์ไบนารี Go เดียว, การกำหนดค่าขั้นต่ำ, อัปเดตเร็ว, รองรับ LDAP
• Forgejo: Git repository โอเพนซอร์ส, Codeberg เป็นอินสแตนซ์หลัก
• Radicle: ระบบควบคุมเวอร์ชันแบบกระจายที่อยู่ในขั้นทดลอง (ประสบการณ์การใช้งานจริงจำกัด)

ข้อมูลจำเพาะของ Codeberg:

• ดำเนินการโดย Codeberg e.V. (องค์กรไม่แสวงหาผลกำไรของเยอรมนี)
• ปฏิบัติตามกฎหมายคุ้มครองข้อมูลของ EU
• รองรับการย้ายข้อมูล repository จาก GitHub, GitLab และบริการอื่นๆ

การทำให้การโฮสติ้ง Static Site ง่ายขึ้น

แง่มุมที่น่าสนใจของการหารือเรื่องการย้ายเกี่ยวข้องกับการคิดใหม่เกี่ยวกับกลยุทธ์การ deploy เว็บ แนวทาง Codeberg Pages แม้ว่าจะแตกต่างจาก GitHub Pages แต่ได้กระตุ้นให้นักพัฒนาบางคนพิจารณาใหม่ว่า CI/CD pipelines ที่ซับซ้อนจำเป็นสำหรับการสร้าง static site แบบง่ายๆ หรือไม่

แนวทางที่แนะนำในการใช้ Git submodules และ shell scripts พื้นฐานแทนที่จะใช้ Actions workflows ที่เต็มไปด้วย YAML แสดงถึงการกลับไปสู่วิธีการ deployment ที่เรียบง่ายกว่า ปรัชญานี้ตั้งคำถามว่าอุตสาหกรรมได้ over-engineer โซลูชันสำหรับงานที่ตรงไปตรงมาอย่างการสร้างและ deploy static websites หรือไม่

การหารือที่กำลังดำเนินอยู่สะท้อนความตึงเครียดที่กว้างขึ้นในชุมชนนักพัฒนาระหว่างความสะดวกและการควบคุม โดยเน้นให้เห็นว่าการพึ่งพาแพลตฟอร์มสามารถสร้างผลกระทบ lock-in ที่ขยายไปเกินกว่าการโฮสต์โค้ดอย่างง่ายไปสู่ development workflows และแนวปฏิบัติด้านการดำเนินงานทั้งหมด

อ้างอิง: HOW AND WHY TO DITCH GITHUB