티스토리 뷰
개발자는 개발 브랜치를 생성하여 소스 코드를 변경하거나 새로운 기능을 추가하고 버전 관리 시스템(GitHub)에 기록(Commit)하고, PR(Pull Request) 및 배포 브랜치(Master Branch)에 통합하는 작업(PR 머지)을 수행합니다.
이 과정은 단일 리포지토리(프로젝트)에서 여러 개발자에 의해 동시다발적으로 진행되며 각자의 작업물을 통합하는 과정에서 서로의 작업이 겹치거나 충돌되지 않는지, 누락된 파일은 없는지 등 통합 이후에 제품이 정상적으로 동작할 수 있도록 철저한 확인 작업을 거쳐야합니다.
확인 작업을 거쳐 작업물이 통합되었다면, 배포 브랜치는 배포 가능한 상태를 유지하기 위해 통합 직후 및 주기적으로 빌드 및 테스트를 진행하여 발생할 수 있는 오류나 버그를 사전에 발견하고 수정하는 작업을 수행합니다.
배포 가능한 상태로 유지된 배포 브랜치는 제품 버전 업데이트, 빌드, 태깅, 배포 과정을 거쳐 최종적으로 사용자에게 전달됩니다.
위에서 나열한 각 과정을 개발자가 직접 수행한다면 많은 시간 및 작업 리소스를 필요로하고, 확인하지 못한 부분이 발생하거나 파일이 누락되는 등 휴면 에러가 발생할 수 있고, 같은 작업을 반복해야하는 번거로움이 있습니다.
버즈빌 클라이언트 팀은 개발 및 배포의 효율을 높히기 위해 CI/CD PipeLine을 형성하여 지속적 통합, 검증, 배포 작업을 자동화 하고, CI/CD 전략을 수립하여 CI/CD PipeLine이 지속적으로 유지될 수 있도록 합니다.
CI
지속적 통합(Continuous Integration)
여러 명의 개발자가 동일한 리포지토리의 각기 다른 기능을 동시에 작업하는 것을 목표로, 동시에 작업 된 소스코드를 배포 브랜치에 병합하려할 때, 다른 개발자의 작업 내용과 충돌을 일으키는 것을 사전에 방지하고 작업된 내용이 제품을 손상시키지 않도록 빌드 및 자동화 테스트를 통해 변경 사항이 제품에 제대로 적용되었는지를 확인합니다.
자동화된 테스트를 통해 기존 코드와 신규 코드간에 충돌을 발견하고 빠르게 수정할 수 있습니다
CD
지속적 제공(Continuous Delivery)
CI의 빌드 자동화, 유닛 및 통합 테스트 이후, 이어지는 프로세스로 언제든지 배포할 준비가 되어있는 코드베이스를 확보하는 것이 목표입니다.
지속적 배포(Continuous Deployment)
CI / CD Pipeline의 마지막 단계로, 출시 준비가 완료된 빌드를 릴리즈하는 작업을 자동화 합니다.
수동 배포 중 발생할 수 있는 Human Error를 방지할 수 있습니다
일반적인 CI/CD PipeLine 구조
기술 스택
GitHub - 형상관리 시스템
CircleCI - 형상관리 시스템(Github, Github Enterprise)과 연계하여 Automated-build/Deployment를 기능을 지원하는 CI/CD 솔루션
Bintray - SDK를 배포하는 Maven 저장소
Firebase Test Lab - 테스트를 실행할 수 있도록 실제 기기와 가상 기기를 제공하는 Cloud Test 솔루션
CodeCov - 코드 커버리지 측정 및 리포팅 서비스
지속적 통합 (CI)
테스트
테스트는 새로운 작업의 결과물이 기능적으로 문제가 없으며 기존의 코드와 잘 호환되는 것을 검증하는 과정으로 작업의 결과물이 배포 브랜치에 포함되어도 문제가 없음을 확인하는 통합 과정에서 가장 중요한 단계입니다.
클라이언트팀 안드로이드 프로젝트는 아래 세가지의 테스트를 수행합니다.
테스트는 모듈 / 앱 단위로 각각 수행됩니다.
a. Lint
코드에 구조적 문제가 없는지 확인하는 정적분석도구
앱을 실행하거나 테스트 사례를 작성할 필요 없이 소스 파일을 검사하여 안정성과 효율성에 영향을 미치거나 코드 관리에 지장을 줄 가능성이 있는 코드를 찾을 수 있습니다.
b. CheckStyle
클라이언트팀의 코딩 컨벤션에 맞게 작성되었는지 코딩 스타일을 확인하는 정적분석도구
주로 코드 포매팅 컨벤션 이슈를 찾아냅니다.
c. Local Unit Test
JVM 환경에서 수행되는 기능단위 부분 테스트
개발자가 작성한 유닛 테스트 코드를 실행합니다. 작성한 코드가 올바르게 동작하고 예측한 결과를 정확하게 도출하는지 테스트하여 코드의 무결성을 검증합니다.
모든 테스트를 통과해야하며, 하나의 테스트라도 통과하지 못할 경우 테스트 실패처리됩니다.
참고하면 좋은 글
https://www.redhat.com/ko/topics/devops/what-is-ci-cd
https://medium.com/flexisaf/git-workflow-for-your-project-3d9dbdc5f8e2
https://aws.amazon.com/ko/devops/continuous-delivery/
https://developers.redhat.com/blog/2017/09/06/continuous-integration-a-typical-process/
https://engineering.linecorp.com/ko/blog/build-a-continuous-cicd-environment-based-on-data/
https://woowabros.github.io/experience/2018/06/26/bros-cicd.html
https://aws.amazon.com/ko/getting-started/projects/set-up-ci-cd-pipeline/
'Android' 카테고리의 다른 글
[Android] Custom Button, Padding 잘 적용하기 (0) | 2021.03.05 |
---|---|
[Hilt] Dagger 보다 쉬운 DI, Hilt (0) | 2021.01.08 |
[Unit Test] 유닛 테스트 Troubleshooting - 2. Rx Scheduler (0) | 2021.01.04 |
[Unit Test] 유닛 테스트 Troubleshooting - 1. android.util.Log not mocked (0) | 2021.01.04 |
[Unit Test] 유닛 테스트 Convention (0) | 2021.01.04 |
- Total
- Today
- Yesterday
- android compose
- android custom button
- 커스텀 버튼
- 알고리즘
- ViewCompositionStrategy
- Leetcode
- 컴포즈 초기화
- 안드로이드 커스텀 버튼
- android test
- 안드로이드 유닛 테스트
- unit test
- button padding
- 테스트
- 유닛 테스트
- AOS
- 구글
- 안드로이드 단위 테스트
- android unit test
- 유닛테스트
- 안드로이드
- compose ui
- 알고리즘 풀이
- 안드로이드 컴포즈
- androud hilt
- Unit
- 코딩테스트
- 안드로이드 테스트
- Android
- 안드로이드 종속성 주입
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |