내일배움캠프 7기 Android TIL 58일차 (2023.10.16)

일일 회고

기획 쭉 하고, UI 구현하고 있다. 쓸 시간이 정말 없다....

오늘의 키워드

합쳐진 코드를 빌드하고, 코드가 컨벤션에 맞춰졌는지 일일이 확인하는 것은 굉장히 귀찮고 시간이 오래 걸리는 작업이다.

그래서 Pull Request를 할 시, 코드가 잘 빌드 되는지 코틀린 컨벤션은 맞춰졌는지를 테스트해보기 위해 간단한 CI를 구성하여 코드를 관리해보고자 하였다.

CI란?

CI(Continuous Integration)

지속적인 통합이라는 의미이다.

개발을 진행하면서도 품질을 관리할 수 있도록 하는 것으로 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다.

CI가 없다면 한 사이클의 개발을 마치고 pull request를 통해 코드를 합친 후, 코드에 오류는 없는지, 올바르게 동작하는 지를 검증하며 코드 품질을 관리할 수 있었다.

CI를 적용하게 되면 각자의 개발자가 자신의 구현해야 할 기능을 구현하면 된다. 코드의 오류는 CI를 통해 자동 빌드를 하며 미리 오류를 찾아낼 수 있다.

이렇게 자동화를하면 개발자가 직접 빌드와 테스트를 직접 하지 않고도 미리 오류를 찾아 낼 수 있고 dev 브랜치에 merge하기 전에 수정 작업을 진행 할 수 있어, merge 후 빌드 테스트를 하지 않아도 되어, 시간 단축 효과를 볼 수 있다.

ci 툴 종류가 굉장히 많다.

이런 것들 중에서 CI 툴을 하나 선택을 했어야 했는데, github actions를 선택을 하였다.

우선, 다른 CI 툴은 서비스 or 설치 형 툴인데, 따로 공부하려면 시간도 많이 들것이라고 생각을 했다.

github action은 github의 repository 내에서 바로 세팅을 할 수 있는 장점이 있어 시간이 많이 들 것 같진 않다고 생각을 하여 선택을 하였다.

또, github과 통합되기 떄문에 빠르게 CI 설정을 해 볼 수 있고 절차가 복잡하지 않다고 생각하였다.

name: CI 이름

on: 어떤 상황이 되었을 떄 action을 실행할지 (push: 특정 브랜치에 푸쉬 됐을 떄, pull_request: 특정 브랜치에 pr을 열었을 떄)

jobs: 어떤 작업을 할 지

build: 빌드 작업을 수행

runs-on: 어떤 OS에서 실행을 할지 (기본 세팅 사용)

steps: 빌드 작업 순서 정의

steps/name: 빌드 작업의 이름

steps/uses: 사용하고자 하는 액션의 위치를 {소유자}/{저장소명}@{참조자}의 형태로 명시 (GitHub에서 제공하는 체크아웃 액션의 소유자는 actions이고, 저장소 이름은 checkout이며 현재 사용 가능한 최신 버전은 v3 임)

run: 실행할 명령어

빌드 실패 이유는 트러블 슈팅에서 기술