지속적 테스트에 빈번하게 등장하는 단어는 CI와 CD가 있습니다.CI 는 이름 그대로 지속적 통합 (Continuous Integratioin)으로 지속적으로 개발자의 작업물(코드)이 완성된 상태의 서비스가 되도록 merge되는 프로세스를 의미합니다.지속적 통합은 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 데브옵스 소프트웨어 개발 방식입니다.지속적 통합은 소프트웨어 릴리스 프로세스 중 빌드 또는 통합 단계를 주로 가리키며,자동화 구성 요소(예: CI 또는 빌드 서비스)와 문화적 구성 요소(예: 빈번하게 통합하도록 학습) 모두를 포함합니다.지속적 통합의 핵심 목표는 버그를 신속하게 찾아 해결하고, 소프트웨어 품질을 개선하고, 새로운 소프트웨어 업데이트를 검증 및 릴리스하는 데 걸리는 시간을 단축하는 것입니다.CD는 지속적 전달(Continuous Delivery)로 이 서비스가 사용자에게 배포되는 프로세스를 의미합니다.지속적 전달(Continuous Delivery)은 프로덕션에 릴리스하기 위한 코드 변경이 자동으로 준비되는 소프트웨어 개발 방식입니다.현대 애플리케이션 개발의 기반인 지속적 전달은 빌드 단계 이후의 모든 코드 변경을 테스트 환경 및/또는 프로덕션 환경에 배포함으로써 지속적 통합을 확장합니다.적절하게 구현할 경우, 개발자는 언제나 즉시 배포할 수 있고 표준화된 테스트 프로세스를 통과한 빌드 아티팩트를 보유할 수 있습니다.지속적 전달에서는 개발자가 단순한 유닛 테스트 외에도 다양한 테스트를 자동화할 수 있으므로,고객에게 배포하기 전에 여러 차원에서 애플리케이션 업데이트를 확인할 수 있습니다.이러한 테스트에는 UI 테스트, 로드 테스트, 통합 테스트, API 안정성 테스트 등이 포함될 수 있습니다.이를 통해 개발자는 업데이트를 좀 더 철저히 검증하고 문제를 사전에 발견할 수 있습니다.온프레미스에서는 힘들었지만, 클라우드에서는 테스트용으로 여러 개의 환경을 생성하고 복제하는 작업을 비용 효율적으로 손쉽게 자동화할 수 있습니다.Gitflow는 Vincent Driessen의 branching model을 적용해 고수준으로 저장소를 관리할 수 있게 해주는 확장 기능입니다.이를 통해 데브옵스를 수행합니다.이 모델은 feature - develop (dev) - release - hotfix - master 단계로 브랜치를 나눠 코드를 관리하는 전략입니다.• None master : 제품으로 출시될 수 있는 브랜치• None develop : 다음 출시 버전을 개발하는 브랜치• None release : 이번 출시 버전을 준비하는 브랜치• None hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치GitFlow 지침은 다음과 같습니다.• None develop을 지속적 통합 브랜치로 사용합니다.• None feature 브랜치를 사용하여 여러 기능에 대한 작업을 수행합니다.• None release 브랜치를 사용하여 특정 릴리스에 대한 작업을 수행합니다(다중 기능).

안녕하세요. 테이블링 백엔드팀의 김재혁입니다.테이블링 백엔드팀은 기존에 AWS CodePipeline과 AWS CodeBuild를 사용해서 프로젝트들의 CI/CD를 관리했는데요. 이번에 일부 프로젝트들은 GitHub Actions를 사용하게 되었습니다.백엔드팀에서 GitHub Actions를 어떻게 사용하는지 공유하려고 합니다.GitHub Actions란?GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 지속적 통합 및 지속적 배포(CI/CD) 플랫폼입니다. GitHub Repository에서 Pull Resquest가 생성되거나 이슈가 만들어지는 등의 이벤트가 발생하면 트리거 되도록 GitHub Actions Workflow(워크플로우)를 구성할 수 있습니다. 예를 들어, Pull Request가 생성되거나 Pull Request의 변경 사항을 적용하거나 추가로 커밋을 푸시하는 경우 자동으로 빌드 및 테스트가 실행되도록 할 수 있습니다.기존 파이프라인의 상황기존에는 AWS CodePipeline과 AWS CodeBuild를 사용하며 gulp.js를 기반으로 동작합니다.gulp.js는 개발 워크플로우에서 번거롭거나 시간이 많이 걸리는 작업을 자동화하는 JavaScript 기반의 도구입니다.아마 gulp.js가 생소하신 분들도 있을텐데요. 다음의 코드와 비슷한 형태로 사용하고 있었습니다.build: commands: - gulp docker:build # (1) - gulp docker:login - gulp docker:build - gulp docker:pushAWS CodeBuild에 사용하는 빌드 사양(buildspec) 파일의 커맨드들이 모두 gulp.js를 사용하는 구조였습니다.만약 (1)을 하는 과정에서 오류가 발생하면 다음과 같은 오류 로그가 출력되었는데요. 빌드에서 실패를 했지만 gulp.js로 Task를 실행했기 때문에 오류 추적을 어렵게 만들었습니다.gulp.js Task에서 발생한 오류그래서 기존 파이프라인을 수정하거나 새로 만드는 것에 대해서 고민을 했는데요. 다음과 같은 이유로 GitHub Actions를 사용하기로 했습니다.백엔드팀에서 코드 관리를 GitHub를 사용하기 때문에 연동성이 좋다.기존에는 AWS CodePipeline을 만들어서 설정을 해야 했지만 YAML 파일을 만들고 저장소에 올리는 것만으로도 CI/CD 파이프라인을 만들 수 있다.Workflow나 Action은 Reusable workflows와 Composite action으로 재사용이 가능하다.GitHub MarketPlace에 우리가 필요로 하는 대부분의 Actions들이 있다.컨벤션과 가이드저희 팀에서는 기존에 YAML 파일을 많이 사용하지 않았습니다. 그래서 처음 YAML 파일을 작성할 때, 파일의 이름을 만들거나 job, step 등의 이름을 만드는 경우에 케밥 케이스, 카멜 케이스, 스네이크 케이스 등의 다양한 방식 중에 어떤 것을 선택해야 할지, 확장자는 .yml, .yaml