GiitHub을 활용한 팀 개발 시 설정에 대해 설명합니다.
14427 단어 GitGitHubGitHub Actionsidea
개요
이 글은 PORT Advent Calander 2020의 글이다.
2020년을 돌이켜보면 GiitHub의 기능을 이용하여 팀 개발을 더욱 효율적이고 편리하게 할 수 있는 몇 가지 설정과 정의가 있기 때문에 총괄하기로 했다.
이 기사는 다음 세 가지를 소개한다.
CI 확인 표준화 검토
리뷰의 누락 방지
Pull Request의 시각화, 활용 표준화
CI 확인 표준화 검토
Branch protation rules 활용
https://github.com/{{team_name}}/{{repo_name}}/settings/branches분기 삭제 금지 또는 설정이 Pull Request 검사 및 CI 제약을 받을 수 있도록 지정합니다.물론 분기별 보호 기능(Force Push 삭제 및 금지 방지)을 사용하고 싶지만, 팀에 대한 코드 검토와 CI 확인을 표준화하는 데 유용한 기능이 있어 활용해 봤다.구체적으로 뭘 설정했는지.
각각 지부 단위로 지정할 수 있기 때문에 릴리플로 등에 따라 탄력적으로 제약을 변경할 수 있다는 점에 초점을 맞췄다.
(추가) 자동 분기 삭제 기능 및 병합 기능
https://github.com/{{team_name}}/{{repo_name}}/settings의 "Merge Button"
리뷰의 누락 방지
Scheduled Reminder 활용
https://github.com/organizations/{{team_name}}/settings/remindersSlack 알림을 통해 Pull Request의 심사 요청과 각 Pull Request에 누가 공이 있는지 알 수 있습니다.매일 신문 스크랩 전 등 정해진 시간에 통지채널에 도착하면 심사를 잊고 잊어버리는 것을 확인하는 데 도움이 된다.이전에는 Pull Panda라는 타사 도구를 사용하다가 GiitHub로 통합되었습니다.
요점은 팀을 사용할 때 팀원들이 각자 각자의 설정을 하는 것이다.
https://github.com/settings/reminders
이렇게 되면 팀에서 사용하는 알림 채널의 GiitHub 사용자 이름이 슬랙 사용자 이름으로 바뀌어 유지보수된다.
또 개인도 직접 댓글 등을 다는 통지를 받아 소홀함을 방지할 수 있다.
Pull Request의 시각화, 활용 표준화
GiitHub Actions로 팀 정의 및 자동화
GiitHub Actions는 트리거 이벤트를 많이 준비했습니다.
분기와 Pull Request 작성 등 트리거 이벤트를 활용하면 트리거될 때 다양한 동작을 할 수 있어 팀 운용 규칙 등을 자동화할 수 있다.이번에는 다음 두 가지를 소개합니다.
1. 마스터가 업데이트되면 개발자를 위한 PR 자동 만들기
git-flow를 통해 마스터에 직접 통합하거나 Release 지점을 통해 조정할 때 마스터 지점의 변경 부분을 개발자 지점에 반영하는 작업이 발생하지만, 이 변경 부분은 자동으로 Pull Request를 생성합니다.
.github/workflows/pulling_into_develop.yml
name: Pulling into develop
on:
push:
branches:
- master
jobs:
pulling_into_develop:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: create-pull-request
uses: repo-sync/pull-request@v2
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
source_branch: 'master'
destination_branch: 'develop'
pr_title: "Pulling ${{ github.ref }} into develop"
pr_body: "Pulling ${{ github.ref }} into develop"
플러그 인이 사용되었습니다
repo-sync/pull-request.Master push에 의해 터치되어 Pull Requet 제작을 실행합니다.
2. 결합된 브랜치에 자동으로 레이블 부여
Pull Request에서 병합된 분기를 쉽게 식별하기 위해 대상 분기 이름 레이블을 추가하는 작업이 자동으로 수행되었습니다.
Pull Request 작성 시 병합 대상을 확인하고 병합 대상 탭을 자동으로 추가합니다.
본 팀은git-flow를 사용하기 때문에 아래 3개는 자동으로 분배됩니다.
플러그 인이 사용 중
actions/labeler입니다.기본적으로 수정된 Path의 조건에 따라 레이블을 분배하기 때문에 이번처럼 목적지 지점을 합병하여 레이블을 분배하기 위해 다음과 같은 정의 파일을 분할하여 대응할 것입니다.
master
.github/workflows/post_processing_for_master.ymlname: Add Label for master branch
on:
pull_request:
types: [opened, synchronize, reopened]
branches:
- master
jobs:
post_processing:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v2
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
configuration-path: '.github/labeler/master.yml'
.github/labeler/master.ymlmerge_to_master:
- "**"
develop
.github/workflows/post_processing_for_develop_branch.ymlname: Add Label for develop branch
on:
pull_request:
types: [opened, synchronize, reopened]
branches:
- develop
jobs:
post_processing:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v2
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
configuration-path: '.github/labeler/develop.yml'
.github/labeler/develop.ymlmerge_to_develop:
- "**"
이외(업무 지점)
.github/workflows/post_processing_for_subtask_branch.ymlname: Add Label for subtask branch
on:
pull_request:
types: [opened, synchronize, reopened]
branches-ignore:
- develop
- master
jobs:
post_processing:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v2
with:
repo-token: "${{ secrets.GITHUB_TOKEN }}"
configuration-path: '.github/labeler/subtask.yml'
.github/labeler/subtask.ymlsubtask:
- "**"
branches-ignore에서 중점을 제외한다.너무 지루해서 다른 플러그인이나 직접 쓰는 게 좋을 것 같아요.최후
가능한 한 자동화팀의 활용을 활용하면 효율을 높일 뿐만 아니라 업무의 범인화를 방지할 수 있다.
기릿허브는 매일 새로운 기능을 추가하기 때문에 효율성을 높이기 위해 자주 포착됐으면 한다.
Reference
이 문제에 관하여(GiitHub을 활용한 팀 개발 시 설정에 대해 설명합니다.), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/kehonda/articles/a5b08e9df03d13텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
