Skip to content

github 프로세스 제안  #14

@amoseui

Description

@amoseui

마일스톤, 프로젝트

  • 마일스톤은 릴리즈 기준, 프로젝트는 스프린트, iteration 등으로 기간으로 관리하는게 편함
    • 프로젝트 보드에 이슈 티켓이 계속 쌓일 것이기 때문에 주기적으로 교체하는게 관리하기 편함 -> 기간 주기
    • 릴리즈 목표 버전 별로 마일스톤을 만들어서 어느 이슈가 어느 버전에 들어갈지 관리
  • 보통 이슈 기준으로 PR을 만들기 때문에 PR은 마일스톤, 프로젝트에 따로 추가할 필요는 없을듯 (중복)
  • PR description 에 이슈 링크를 추가하거나 Linked pull requests 등으로 1:1 링크도 가능

업무에서 사용하는 설정 + 개인 github 세팅

  • 리뷰 프로세스 관련
    • Settings > Branches > Branch protection rules (master branch)
      • 보통 체크하는 것
      • Require a pull request before merging
        • Require approvals (리뷰, 빌드 등)
        • Dismiss stale pull request approvals when new commits are pushed
        • Require review from Code Owners (선택, CODEOWNERS 파일로 폴더/파일 단위로 리뷰어 관리 가능)
      • Require status checks to pass before merging (CI 가 있는 경우 어떤 job을 require 할 것인지 설정 가능)
        • Require branches to be update before merging
  • Merge 방법
    • Settings > Options > Merge button
      • Allow squash merging 만 체크
        • 하나의 PR 당 하나의 commit 으로 submit 됨, 브랜치 분리, merge commit 없이 linear 하게 히스토리 관리돼서 보기 편함
        • PR에서 리뷰 중 추가 수정이 필요할 때는 amend 옵션 없이 추가 commit 을 새로 만들어서 올려서 추가 수정을 확인
        • merge 할 때는 하나로 합쳐서 submit됨

CI 에서 확인하면 좋은 것

  • test coverage
    • gradle 에 jacoco 로 test coverage 추가
    • codecov, coveralls 등 외부 툴을 이용해서 PR에 봇이 comment 를 달거나 웹 UI로 따로 볼 수 있음
  • 코드 스타일 등 -> ktlint? detekt? 자동으로 확인

Metadata

Metadata

Assignees

No one assigned

    Labels

    DevOpsbuild, delivery pipeline

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions