GitHub เผยเบื้องหลัง Evergreen ระบบจัดการ Repo อัตโนมัติ

การทำงานร่วมกับผู้ร่วมงานภายนอก (outside collaborators) อาจเพิ่มภาระงานให้กับเจ้าของ repository อย่างมาก คุณจำเป็นต้องยืนยันความต้องการเข้าถึงข้อมูล ปรับเปลี่ยนสิทธิ์ตามความคืบหน้าของโปรเจกต์ และต้องจัดเก็บ (archive) repository เมื่อเสร็จสิ้นภารกิจ

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

GitHub เผชิญกับปัญหานี้ในองค์กรส่วนกลางที่พนักงาน ("Hubbers") ต้องทำงานร่วมกับลูกค้าและพาร์ทเนอร์ เราจึงสร้าง Evergreen ซึ่งเป็น GitHub App ที่พัฒนาขึ้นจากฟีเจอร์พื้นฐานของ GitHub โดยคุณสามารถนำเวิร์กโฟลว์นี้ไปปรับใช้กับองค์กรของคุณได้เช่นกัน

ทำความรู้จักกับ Evergreen

Evergreen ช่วยจัดการความสะอาดขององค์กรโดยอัตโนมัติผ่าน 2 เวิร์กโฟลว์หลัก:

1. การตรวจสอบสิทธิ์การเข้าถึงของผู้ร่วมงานภายนอก: ตรวจสอบรายชื่อทุกไตรมาสเพื่อคงสิทธิ์เฉพาะผู้ที่จำเป็นต้องใช้งานต่อ และลบชื่ออื่นออก
2. การตรวจจับและจัดเก็บ repository ที่ไม่ได้ใช้งาน: ติดธงและเตือน Repo ที่ไม่มีกิจกรรมจากมนุษย์เกินเกณฑ์ หากไม่มีการตอบรับ ระบบจะทำการจัดเก็บโดยอัตโนมัติ

การออกแบบระบบยึดถือหลักการสำคัญสองประการ คือ Fail secure ซึ่งจะเพิกถอนสิทธิ์ทันทีหากไม่มีการตอบรับการตรวจสอบเพื่อความปลอดภัยสูงสุด และ ไม่ทำลายสิ่งใดเลย โดย Evergreen จะไม่ลบเนื้อหาถาวร แต่ใช้วิธีจัดเก็บที่กู้คืนได้ พร้อมบันทึกทุกการเปลี่ยนแปลงไว้ใน tracking issue ของ repo เพื่อให้แก้ไขกลับคืนได้ง่าย

ทำงานอย่างไร: หนึ่งสมอง หลายมือ

Evergreen ทำงานเป็น Go webhook server ขนาดเล็กใน container แต่หัวใจสำคัญคือการประสานงาน (choreography) ผ่านฟีเจอร์มาตรฐานของ GitHub ทั้งหมด ไม่ว่าจะเป็น GitHub App, scheduled actions, webhooks, issues, custom properties และไฟล์ใน repo โดยไม่ต้องประดิษฐ์เครื่องมือใหม่

คอนโทรลเลอร์ที่รักษาเวลา

controller repo ทำหน้าที่เป็นนาฬิกาและหน่วยความจำหลัก โดยมี GitHub Actions 4 ชุดคอยส่งเหตุการณ์ repository_dispatch ตามรอบรายไตรมาสเพื่อให้แอปทำงานดังนี้:

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

สถานะที่คุณสามารถ git blame ได้

Evergreen เก็บสถานะของทุก repo เป็นไฟล์ JSON ไว้ใน controller repo ภายใต้ state/repos/<repo_id>.json ข้อมูลทั้งสแนปชอตผู้มีสิทธิ์, กำหนดส่ง และการตัดสินใจจะถูกบันทึกไว้ที่นี่ทั้งหมด

{
  "repo_id": 123456789,
  "full_name": "the-org/acme-trial",
  "last_seen_at": "2026-04-13T00:05:00Z",
  "access_review": {
    "deadline": "2026-04-27T00:00:00Z",
    "status": "renewed",
    "collaborators_at_open": [
      { "login": "alice", "name": "Alice Example", "permission": "admin" },
      { "login": "bob", "name": "Bob Example", "permission": "write" }
    ],
    "renewed_logins": ["alice"],
    "decided_by": "carol-hubber",
    "decided_at": "2026-04-15T16:42:10Z",
    "tracking_issue": { "repo_id": 123456789, "number": 42 }
  },
  "staleness": {
    "last_activity_at": "2026-04-15T16:42:10Z",
    "warned_at": null,
    "archive_deadline": null,
    "status": "active",
    "tracking_issue": null
  }
}

ข้อดีคือประวัติการคอมมิต (commit history) จะทำหน้าที่เป็นเส้นทางการตรวจสอบ (audit trail) ไปในตัว ทำให้เราย้อนดูสาเหตุการเปลี่ยนแปลงสิทธิ์ได้ผ่าน git log โดยไม่ต้องพึ่งพาฐานข้อมูลภายนอก

Issue-ops ในทุกที่ที่สำคัญ

การสื่อสารทั้งหมดทำผ่าน issue ภายในแต่ละ repository โดยเมื่อเริ่มตรวจสอบ ระบบจะสร้าง checklist issue เพื่อให้ผู้ดูแลตัดสินใจ

วิธีการใช้งานเรียบง่ายเพียงแค่ ติ๊กถูกเลือกคนที่ต้องการให้คงสิทธิ์ไว้แล้วปิด issue เมื่อปิดแล้ว Evergreen จะรับเหตุการณ์ issues.closed ผ่าน webhook เพื่อดำเนินการตามที่เลือก พร้อมโพสต์คอมเมนต์สรุปผลการดำเนินงานทันที

มนุษย์ที่เหมาะสมเท่านั้นที่ดึงคันโยกได้ เพื่อความปลอดภัย Evergreen จะอนุญาตให้เฉพาะบุคคลที่มีสิทธิ์ (Hubbers) เท่านั้นที่ปิด issue ได้ หากบุคคลอื่นพยายามปิด แอปจะเปิด issue นั้นขึ้นมาใหม่โดยอัตโนมัติพร้อมแจ้งเหตุผล

แจ้งข้อมูลให้ถูกคน

Evergreen มีระบบการค้นหาเจ้าของ repository เพื่อแจ้งเตือนผ่านลำดับ fallback chain:

1. ตรวจสอบจาก custom property ชื่อ evergreen_repo_owner
2. หากไม่มี ให้พิจารณาจากผู้เขียน issue และ commit ล่าสุด รวมถึงทีมที่กำลังทำงานใน repo นั้นจริงๆ

วิธีนี้ช่วยให้สามารถแจ้งเตือนผู้รับผิดชอบได้โดยตรงโดยไม่ต้องอาศัยการดูแล spreadsheet แยกต่างหาก

Fail secure และ fail closed

หากพ้นกำหนดโดยไม่มีการตอบรับ ระบบจะเพิกถอนสิทธิ์ผู้ร่วมงานทุกคน แต่หากเกิดข้อผิดพลาดทางเทคนิค (API error) Evergreen จะใช้หลักการ fail closed โดยจะคงสถานะรอดำเนินการและเปิด issue ค้างไว้จนกว่าการลบทุกรายการจะสำเร็จจริง เพื่อป้องกันความไม่สอดคล้องของข้อมูล

ประสบการณ์ผู้ใช้: ระบบอัตโนมัติที่ให้ความรู้สึกเกรงใจ

เราออกแบบ Evergreen ให้ทำงานอย่างเป็นมิตรและไม่รบกวนผู้ใช้เกินความจำเป็น โดยการนำงานไปหาผู้ใช้ถึงที่ใน repo ของตนเอง แท็กบุคคลที่เกี่ยวข้องอย่างแม่นยำ แจ้งกำหนดการและผลกระทบชัดเจนล่วงหน้า และยังมีช่องทางยกเว้น (exempt) สำหรับกรณีพิเศษผ่าน custom property

การเริ่มใช้งานอย่างระมัดระวัง

ในองค์กรขนาดใหญ่ที่มีพนักงานกว่า 1,400 คน เราให้ความสำคัญกับการเริ่มใช้งานเป็นอย่างมาก โดยมีขั้นตอนดังนี้:

• Dry-run ก่อน: ใช้โหมดทดสอบเพื่อดู log การทำงานโดยไม่แก้ไขจริงจนมั่นใจ
• สื่อสารให้มากเข้าไว้: ประกาศแผนงานล่วงหน้าหลายครั้งเพื่อให้แน่ใจว่าทุกคนรับทราบ
• เฝ้าดูด้วย Splunk: ส่ง log ไปยังระบบสังเกตการณ์เพื่อตรวจพบกรณีพิเศษและปรับแต่งลอจิกให้รัดกุม
• เคารพขีดจำกัดของแพลตฟอร์ม: เนื่องจาก GitHub มี secondary rate limits ระบบจึงประมวลผลเป็นชุดๆ และเว้นระยะการเรียกใช้งานเพื่อป้องกันปัญหา

บทเรียนที่ได้รับ

การสร้าง Evergreen สอนให้เราใช้หลัก fail secure เป็นค่าเริ่มต้น และใช้เครื่องมือพื้นฐานที่มีอยู่ให้เกิดประโยชน์สูงสุด การเข้าถึงผู้คนในพื้นที่ทำงานจริงอย่าง issue ช่วยให้การจัดการง่ายขึ้น และการเก็บบันทึกผ่านประวัติ git ก็ช่วยให้การตรวจสอบย้อนหลังทำได้ทันที

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

พร้อมที่จะทำให้การดูแลความเรียบร้อยของ repository เป็นกิจวัตรแล้วหรือยัง? เริ่มต้นจากงานเล็กๆ แล้วขยายผลด้วย GitHub Apps และระบบอัตโนมัติตามความต้องการของคุณ