▲

GN⁺: Github 액션을 다시 사용하기 전에 한번 더 생각해보려고 합니다

 (ninkovic.dev)
4P by neo 12일전 | ★ favorite | 댓글 5개
  • GitHub Actions에 대한 불만
    • 팀은 약 15명의 엔지니어로 구성되어 있고, 모두가 main 브랜치에 지속적으로 코드를 푸시함
    • 코드는 여러 모듈로 나뉜 Monorepo 형태로 존재하며, 트렁크 기반 개발 방식을 통해 하루에도 여러 번 배포됨
  • GitHub Actions를 좋게 사용하는 경우도 있지만, 특정 규모나 환경에서는 한계가 명확하게 드러남

Pull request와 필수 체크사항

  • 모노레포가 여러 폴더로 나뉘어 있고, 각 폴더마다 독립적으로 테스트, 빌드, 배포를 진행함
  • GitHub Actions paths 기능을 사용하여 특정 폴더 변경이 있을 때만 해당 파이프라인을 트리거함
  • Pull request 병합 전 모든 체크가 통과되어야 하는 상황은 좋은 원칙이지만, 모노레포 구조와 결합될 때 문제가 발생함
    • 예: web-app1 - Unit tests라는 체크를 ‘필수’로 설정했는데, web-app1 폴더에 변경사항이 없으면 그 체크가 실행되지 않음
    • 그 결과, 한쪽 폴더만 변경되어도 다른 폴더 관련 테스트가 실행되지 않아 병합 자체가 불가능해지는 문제 발생함
  • GitHub 측에서 필수 체크의 이름이 아니라, “현재 트리거된 체크 전부가 통과되면 병합 가능” 같은 방식으로 처리가 되면 해결 가능할 텐데 3년째 변경이 없다는 점이 안타까운 상황임
  • 관련 GitHub 이슈 스레드 1, 2에서도 이 문제의 큰 영향을 확인할 수 있음
  • 결국 이를 우회하기 위해 추가 파이프라인을 실행하거나 유지보수하기가 복잡하고 비용이 많이 드는 상황임

재사용성과 YAML

  • 파이프라인 규모가 커질수록 GitHub Actions로 관리하기가 점점 어려워지는 느낌임
    • 많은 if 문이 들어가게 되고, 워크플로우를 분리해도 관리할 파일이 많아져서 유지보수성이 떨어짐
  • 재사용할 때 한 줄로 끝나야 할 호출 부분도 여러 줄과 중복 설정이 필요하여 .github 폴더에 이미 30개 이상의 파일이 쌓여 있음
  • needs 절도 리팩토링 시 삭제된 잡을 반영하지 못하면 에러를 발견하기까지 시간이 걸림
  • GitHub Actions를 로컬에서 실행할 수 없어 개발과 테스트가 까다로움
    • act 같은 도구가 있지만, 실제 사용 시 제약이 많아 기대에 미치지 못하는 경우가 많음

GitHub의 무관심

  • 위 문제점 중 가장 큰 문제는 GitHub가 이 이슈들을 별로 중요하게 생각하지 않는 것처럼 보인다는 점임
  • 여러 이슈가 수년째 열려 있고, 공개 로드맵에 포함되지 않았다는 점에서 개선 의지가 없어 보임
  • 한동안 오랫동안 거론되던 문제들도 최근 이슈가 대거 닫혔음으로써 커뮤니티 반발이 있었음

옵션

  • 이런 문제와 GitHub의 개선 의지 부족을 고려하면, GitHub Actions 도입 전 신중해질 필요가 있음
  • 시장에는 Gitlab, Jenkins, TeamCity 등 다른 CI/CD 옵션이 다양함
  • Dagger 같은 새로운 접근법을 제시하는 도구도 검토할 가치가 있음
▲
devsepnine 10일전  [-]

저두 깃랩 쓰다가 깃헙 액션 환경에 놓였을땐 되는게 없네 싶었던 기억이 ...

답변달기
▲
jjpark78 11일전  [-]

깃허브에 저장소들을 그룹별로 묶어서 관리가 안되는것도 저는 큰 불만중에 하나..

답변달기
▲
jjpark78 11일전  [-]

파이프라인은 깃랩이 정말 좋은거 같아요. 위에서 말한거 깃랩은 다 되거든요.
모노리포일 경우에 테스트를 어떤 폴더가 변경되면 무엇무엇 무엇이 실행되어야 한다라고 설정하기 개편함.

답변달기
▲
tujuc 12일전  [-]

이건 GitHub Actions의 역사를 알아야 되는거긴한데...

최초의 GItHub Actions는 지금의 상황과 다른 양상을 보이고 있었죠...
Open 하기 6개월이전에 (기억이 가물가물) GitHub이 MS에 인수가 되었고 Actions 개발은 MS에서 Azure DevOps 팀과 작업을 같이하기로 했던거같습니다.
이때 Azure DevOps에 새로운 기능이 더이상 나오지 않았고, Azure DevOps에 있던 기능들이 GitHub Actions에서 새로운 기능이 나오고 있었던...
그때 Yaml로 변경되었고 지금의 환경이 만들어졌었죠.... ㅠ.ㅠ

이후로 개발자들이 원 파트로 돌아가고 더이상 손을 보고 있지 못한 상태로 보이는지라...
아쉽네요...
지금 회사에서는 GitHub Actions 기반으로 CI/CD를 구성해놨는데... 아직은 부족한 점이 없어서 사용을 하고 있는데...

주시고 하고 있어야겠네요...

답변달기
▲
neo 12일전  [-]
Hacker News 의견

  • 파이프라인 DSL에 실제 로직을 포함하지 않고, 작업을 조정하는 데만 사용해야 함. 복잡한 작업은 스크립트로 만들어서 간단하게 실행할 수 있도록 해야 함. 이를 통해 GitHub Actions, Jenkins, Azure DevOps 등에서 동일한 작업을 간단하게 수행할 수 있음

  • GitHub Actions를 설정할 때, 사전 제작된 액션을 피하고, 단순한 셸 실행기로 사용하는 것이 좋음. Python, Ruby, Bash 등으로 스크립트를 작성하고 GitHub Action에서 이를 실행하면 로컬 테스트가 쉬워지고, 불필요한 고통을 줄일 수 있음

  • GitHub Actions는 특정 조건이 충족될 때만 검사를 실행할 수 있음. 하지만 이러한 규칙을 사용하면 "Pull request와 필수 검사" 문제에 직면하게 됨. 외부 서비스와 함께 사용할 때 필수 검사는 반드시 통과해야 하며, 그렇지 않으면 병합할 수 없음

  • 'Pull request와 필수 검사' 문제를 해결하기 위한 방법으로, 각 필수 검사 워크플로우의 'no op' 버전을 생성하여 조건이 충족되지 않을 때 이를 실행하고 코드 0으로 종료하게 할 수 있음. 이 방법은 기본 기능이지만 다소 복잡한 해결책임

  • Travis CI는 로컬에서 CI를 테스트하기에 훌륭했음. GitHub Actions는 GitLab CI와 경쟁하기 위해 만들어졌으며, 기업 시장에서 점유율을 잃고 있었음

  • Buildkite를 사용해 볼 것을 추천함. GitHub Actions를 넘어서면 Buildkite가 좋은 대안이 될 수 있음. 대규모 미국 기술 회사에서 사용한 경험이 있으며, CI의 유일한 즐거운 부분이었음

  • GitHub Actions의 아키텍처는 보안 결정을 잘못 내리게 할 수 있음. 예를 들어, 조직 또는 저장소 비밀은 편리하지만 보안 취약점이 될 수 있음. 저장소 환경은 별도의 비밀을 가질 수 있지만, 올바른 워크플로우가 올바른 환경에만 접근할 수 있도록 해야 함

  • CI 시스템의 일반적인 철학은 잘못되었음. CI가 코드를 실행하는 대신, 코드가 CI를 실행해야 함. CI는 API를 제공하여 사용자가 시스템에 정보를 제공할 수 있도록 해야 함

  • Bazel을 사용하여 CI 도구가 Bazel 타겟을 빌드하도록 하고, 필요할 때 원격 빌드 실행을 통해 병렬성을 높일 수 있음. 이는 약 10M+ 라인 코드 또는 대규모 서비스에 적합함

  • GitHub에서 "필수 검사"를 지정할 수 있으며, 이는 항상 녹색이어야 함. 하지만 특정 폴더에 변경이 있을 때만 실행되므로, 다른 폴더에 변경이 있을 경우 병합할 수 없음. 모든 테스트를 실행하지 않으면 통합의 의미가 없어지므로, 테스트를 빠르게 실행할 수 있도록 해야 함

답변달기