👋 CI를 도입한 이유
Tuist를 도입하여 우리는 각자 독립된 환경에서 필요한 부분만 빌드하는 이점을 살려
개발의 생산성을 높혀 나가고 있었다.
그런데 여기서 예상치 못한 변수가 등장했다..
바로 빌드되는 부분을 제외한 곳의 디버깅이 안되는 상황이다.
현재 BaseFeature의 타겟을 빌드하게 되면 다른 타겟쪽은 빌드가 돌아가지 않기 때문에 컴파일 에러를 잡아낼 수 없다.
그렇게되면 우리의 규칙인 pr단위는 반드시 빌드가 되야한다라는 규칙이 깨지게된다.
실제로 ci 도입 전 많은 pr은 굉장히 안전하지 않아고 실제로 pull을 받았을 때 빌드가 안되는 문제가 많았다.
이제부터 ci를 통해 범인 찾기와 범인 발생 자체를 최대한 막아보려고 한다.
⏰ 언제 검사할까??
가장 먼저 고민해야할 부분은 action이 돌아갈 시점을 결정해야한다.
모든 액션에 action이 돌아가면 좋겠지만 걸리는 시간이 길어질수록 생산성이 오히려 더 떨어지는 단점이 있기때문에
꼭 필요한 부분만 돌아가야한다.
그렇다면 돌아가는 부분은 어떻게 정의할 수 있을까??
1. 중요한 브랜치에 업데이트가 될 떄
- PR
- PUSH
2. 컴파일 에러를 발생할 수 있는 파일의 업데이트
- 컴파일 에러는 .swift 파일이 수정되야 가능하므로 .swift를 업데이트에 포커싱한다.
3. 현재 action 스크립트 업데이트
- action 스크립트가 업데이트 되었다면 해당 action 스크립트가 원격 CI 서버에서 잘 돌아가는 지 확인해야한다.
위 조건을 CI 스크립트로 정리하면 다음과 같다.
코드
name: CI
on:
pull_request:
paths: # PR에 CI 파일이 변경되었거나, 어떤 디렉토리건 swift 확장자 파일이 변경되었을 경우 실행
- ".github/workflows/CI.yml"
- "**/**.swift"
push:
branches: [ develop, "epic/**", "story/**" ]
...
🚧 test를 하기전 준비해야할 것
테스트를 바로 들어갈 수 없다. 왜냐하면 CI서버에는 어떤 환경설정이 되어있지 않고 그냥 비어있는 상태이다.
그래서 가장 먼저할 작업은 test를 위한 사전작업이다.
먼저 해야하는 사전 작업을 알아보자.
1. 코드 다운 받기
- 여기서 실제 레포지토리에 있는 코드들을 다운 받는다.
- 소스코드 , 리소스등 레포지토리에 있는 모든 파일을 다운 받는다.
2. 외부 의존성
- 위 과정에서 소스코드만 다운 받으면 한가지 빠진 부분이 있다.
- 바로 오픈소스를 받아오지 않은 상태이다.
- 그렇기 때문에 외부 의존성을 받아와야한다.
여기서 고민할점은 외부 의존성의 변화가 없는데도 항상 받아와야할까??
나는 그렇지 않다고 생각한다. 그래서 찾아보니 gitaction에서 cache 기능을 제공한다.
Tuist의 외부 의존성은 Package.swift 파일에 명시되는데 이 파일에 변화가 없으면 굳이 외부 의존성을
업데이트 할 필요가 없을 것 같다.
즉, Package.swift의 내용을 캐싱에 사용하면 될 것 같다.
자세한 내용은 관련 작업을 하며 적은 포스팅을 봐주길 바란다.
유용한 Marketplace workflow
들어가기 전이전 시간에 우리는 workflow 구조에 다양한 키워드를 살펴봤다.거기서 uses 키워드를 이용해 이미 만들어진 것을 이용할 때 유용한 Marketplace action들을 모아 놓으면 추후 workflow를 만들
hamp.tistory.com
코드
jobs:
prepare-ci: # job 생성, 캐시 설정
name: 🚧 Prepare CI # job 이름 설정
runs-on: macos-14 # 가상환경 설정
steps: # steps 키를 통해 순차적인 수행할 작업 명시
- uses: actions/checkout@v3 # 원격 저장소에서 CI서버로 코드 내려받기
- name: Select Xcode 16.0
run: sudo xcode-select -s /Applications/Xcode_16.0.app/Contents/Developer
# 의존성 캐싱 key 계산
- name: Compute package dependency cache key
id: compute_package_hash
run: echo "package_hash=${{ hashFiles('Package.swift') }}" >> $GITHUB_OUTPUT
# hashFiles(path): 일치하는 hashSet 반환 ,그 값을 outpus에 담음
# steps.cache_package_dependencies.outputs.package_hash = hash 값
# key에 해당하는 값이 path에 있을 경우, 그 파일을 가져오고 없다면 key에 해당 path를 저장하여 캐싱
- name: Check package dependency cache
uses: actions/cache@v3
id: cache_package_dependencies
with: # cache@v3에 사용할 파라미터 명시
path: ${{ env.CACHED_PACKAGE_DEPENDENCY_PATHS }}
key: ${{ steps.compute_package_hash.outputs.package_hash }}
# steps.cache_package_dependencies.outputs.cache-hit = cache-hit 여부 저장
- name: Echo dependency cache hit
run: echo "package cache hit = ${{ steps.cache_package_dependencies.outputs.cache-hit }}"
- uses: jdx/mise-action@v2 # mise 설치
- name: 🛜 Install Tuist
run: mise install tuist
- name: 📦 Install dependencies needs
if: steps.cache_package_dependencies.outputs.cache-hit != 'true'
run: make install
outputs: # 다른 job에서 접근할 수 있게 output 값을 job 수준으로 끌어올림
package_dependency_cache_key: ${{ steps.compute_package_hash.outputs.package_hash }}
🧪 본격적인 test 실행
위에서 test를 위한 사전준비가 끝났다면 사실상 tuist를 이용한 테스트 그렇게 어렵지않다.
tuist test
명령어를 하면 각 모듈에 대한 테스트를 진행하기 때문이다.
test: # test job 생성
name: 🧪 Test
runs-on: macos-14 # 가상환경 설정
needs: prepare-ci # 선행작업
steps: # steps 키를 통해 순차적인 수행할 작업 명시
- uses: actions/checkout@v3 # 원격 저장소에서 CI서버로 코드 내려받기
- name: Select Xcode 16.0
run: sudo xcode-select -s /Applications/Xcode_16.0.app/Contents/Developer
- uses: jdx/mise-action@v2
- name: 🛜 Install Tuist
run: mise install tuist
- name: Check package dependency cache
uses: actions/cache@v3
id: cache_package_dependencies
with:
path: ${{ env.CACHED_PACKAGE_DEPENDENCY_PATHS }}
key: ${{ needs.prepare-ci.outputs.package_dependency_cache_key }}
- name: 📦 Install dependencies needs
if: steps.cache_package_dependencies.outputs.cache-hit != 'true'
run: make install
- name: "🧪 Start Test"
run: make test
🔨 결과 및 소감
결과를 보면 CI 서버에서 놓쳤던 컴파일에러를 잡아주기때문에 develop 같은 안전성이 중요한 브랜치에
합쳐지기 전의 오류를 바로 고칠 수 있었다.
또한 외부 의존성 설치여부를 캐싱을 통해 비교하여 불필요한 의존성 설치시간을 건너 뛸 수 있어
약 1분에서 길게는 2분까지의 CI 시간을 단축 시킬 수 있었다.
'Git > action' 카테고리의 다른 글
유용한 Marketplace workflow (1) | 2024.11.17 |
---|---|
workflow 만들기 (0) | 2024.11.17 |
gitAction과 구조 (0) | 2024.11.17 |