KCH W07 · 개발자가 일하는 방식
공개 저장소부터 개발·배포를 진행합니다. Issue 라벨·브랜치 이름·PR 관례를 익히고, Actions의 임시 컴퓨터에서 CI를 실행해 통과한 변경만 main에 합치도록 설정합니다.
시작하기
발표 모드 — 내부 step 자동 재생 · Space 다음 slide · ← → slide 이동 · ? 도움말 · Esc 미리보기
학습 목표
이 강의를 끝내면 다음을 할 수 있다.
- 1 Issue 라벨과 브랜치 이름을 팀 관례로 정하고 작업·PR과 연결한다.
- 2 Actions·runner·워크플로·CI/CD를 구분하고 별도 환경의 설치·검사 순서를 설명한다.
- 3 실제 ci 이름을 main 보호 조건에 연결하고 실패 시 병합이 막히는지 확인한다.
커리큘럼
- 01 저장소·Issue·라벨과 브랜치 관례6장
- 02 개발·PR·첫 배포와 팀 협업4장
- 03 Actions의 컴퓨터와 CI 실행3장
- 04 main 필수 검사와 배포 확인3장
마무리
오늘의 한 줄
“저장소부터 개발·배포를 경험하고 팀원의 변경을 PR과 자동 검사로 확인해 사용자에게 전달합니다.”
Q&A
강의 들으면서 가장 많이 받는 질문 2개.
Q. 앞 주차와 무엇이 다른가요? ▶
5·6주차에서 정한 범위와 동작을 개발하고 전달합니다. 기존 기능 보호는 팀원의 추가 변경을 검토하고 합치는 과정에서 심화합니다.
Q. 혼자서도 따라 할 수 있나요? ▶
저장소·Issue·브랜치·PR·자동 검사까지 할 수 있습니다. 팀원 승인을 필수로 했다면 쓰기 권한이 있는 실제 파트너가 필요합니다.
실습 과제
강의 듣고 직접 손으로 해봐야 남는다. 1개 과제.
- 과제 01
장비관리 변경 하나를 PR과 배포까지 연결하기
공개 가능한 저장소에 라벨과 브랜치 이름 관례를 정한다. Issue #12 반납 예정일을 feature/12-loan-due-date에서 개발하고 PR로 검토를 요청한다. Ubuntu runner에서 설치·check·test·build를 실행하고 ci를 main 필수 검사로 지정한다. 일부러 실패한 검사에서 병합이 막히는지 확인하고 수정·승인·병합·배포 후 실제 결과를 남긴다.
▶ 힌트 보기
파트너가 없다면 PR·검사까지 진행하고 승인은 미완료로 남긴다. 브랜치는 데이터베이스를 자동 분리하지 않으며 무료 Actions와 호스팅 비용은 별도다. 라벨은 분류용이고 자동으로 병합을 막지 않는다. 검사 이름과 보호 설정의 이름을 맞춘다.
▶ 풀이 예시
저장소·Issue·PR 주소, 실제 검토·검사 결과, 보호 설정, 배포 버전·주소와 다른 기기의 저장·조회 결과를 남긴다. 계획·확인·미완료를 구분한다.
다음 강의 예고
KCH W08 · 팀원이 바로 시작할 수 있는 Issue 만들기
공통 규칙을 맞추고 따로 개발·확인할 수 있는 Issue를 나눕니다. 불필요한 기다림을 줄이고 남은 선행 관계를 기록합니다.
강사
백상현