지속적 통합을 위한 초보자 가이드

fleetster에는 자체 GitLab 인스턴스가 있으며 GitLab CI/CD에 많이 의존합니다. 또한 디자이너와 QA 직원도 진보된 기능 덕분에 GitLab을 사용하고 좋아합니다.

GitLab CI/CD는 매우 강력한 지속적 통합 시스템으로, 다양한 기능이 포함되어 있으며, 새로운 버전이 나올 때마다 새로운 기능이 탑재됩니다. 매우 풍부한 기술 문서가 있지만 기존 설정에서 사용하고자 하는 사람들을 위한 일반적인 소개가 부족합니다. 디자이너나 테스터는 Kubernetes를 사용하여 자동 확장하는 방법이나 이미지 또는 서비스 간의 차이를 알 필요가 없습니다.

하지만 여전히 파이프라인이 무엇인지, 환경에 배포된 브랜치를 확인하는 방법을 알아야 합니다. 따라서 본 글에서는 가능한 한 많은 기능을 다루고, 최종 사용자가 어떻게 즐길 수 있는지 강조하려고 합니다. 지난 몇 달 동안 이러한 기능을 일부 팀원과 개발자에게 설명했는데, 모든 사람이 지속적 통합이 무엇인지 알거나 이전 업무에서 GitLab CI/CD를 사용한 적이 있는 것은 아닙니다.

지속적 통합이 중요한 이유를 알고 싶다면 이 글을 읽는 것이 좋으며, 특히 GitLab CI/CD를 사용하는 이유를 찾기 위해서는 GitLab을 이용한 지속적 통합을 참고하세요.

소개

개발자는 일부 코드를 변경할 때마다 변경사항을 커밋에 저장합니다. 그런 다음 해당 커밋을 GitLab에 푸시하면 다른 개발자가 코드를 검토할 수 있습니다.

GitLab CI/CD가 구성된 경우, GitLab은 해당 커밋에 대한 몇몇 작업도 시작합니다. 이 작업은 Runner가 실행합니다. Runner는 기본적으로 .gitlab-ci.yml 파일에 나열된 명령을 실행하고 그 결과를 GitLab 자체에 다시 보고하여 GitLab의 그래픽 인터페이스에 보여주는 서버(여러 가지 다른 것이 될 수 있고 PC도 될 수 있지만, 서버로 단순화할 수 있음)입니다.

개발자가 새로운 기능이나 버그 수정(일반적으로 여러 커밋을 요구하는 활동)의 구현을 완료하면 팀의 다른 구성원이 코드 및 구현에 대해 의견을 제시할 수 있는 병합 요청(Merge Request)을 열 수 있습니다.

앞으로 알게 되겠지만, 디자이너와 테스터는 이 프로세스에 참여할 수 있으며(그리고 정말로!), 특히 GitLab CI의 두 가지 기능인 환경 및 아티팩트 덕분에 피드백을 제공하고 개선사항을 제안할 수 있습니다.

Pipelines

GitLab에 푸시되는 모든 커밋은 해당 커밋에 연결된 파이프라인을 생성합니다. 여러 커밋이 함께 푸시되면 마지막 커밋에 대해서만 파이프라인이 생성됩니다. 파이프라인은 여러 단계로 나뉜 직업들의 모음입니다.

동일한 단계의 모든 작업이 동시에 실행되며(충분한 Runner가 있는 경우), 이전 단계의 모든 작업이 성공한 경우에만 다음 단계가 시작됩니다.

작업이 실패하면 전체 파이프라인이 실패합니다. 아래에서 볼 수 있듯이, 이에 대한 예외가 있습니다. 작업이 수동으로 표시된 경우, 실패로 인해 파이프라인이 실패하지 않습니다.

단계는 작업 배치 간의 논리적 구분일 뿐이며 이전 작업이 실패한 경우 다음 작업을 실행하는 것은 의미가 없습니다. 애플리케이션을 빌드하기 위한 모든 작업이 실행되는 build 단계, 빌드된 애플리케이션이 배포되는 deploy 단계를 가질 수 있습니다. 빌드에 실패한 것을 배포하는 것은 말이 안 되지 않습니까?

모든 작업은 동일한 단계의 다른 작업과 종속성이 없어야 하며 이전 단계의 작업 결과를 기대할 수 있습니다.

GitLab이 단계 및 단계 상태에 대한 정보를 어떻게 표시하는지 살펴보겠습니다.

docs/image/cicd/pipeline-overview.png

Jobs

작업은 Runner가 실행해야 하는 명령 모음입니다. 작업의 결과물(Output)이 무엇인지 실시간으로 볼 수 있으므로, 개발자는 작업이 실패한 원인을 이해할 수 있습니다.

작업은 자동이 될 수 있으므로 커밋이 푸시되면 자동으로 시작되거나 수동으로 시작됩니다. 수동 작업은 누군가에 의해 수동으로 트리거 되어야 합니다. 예를 들어, 이는 배포를 자동화하는데 유용할 수 있지만 여전히 누군가가 수동으로 승인한 경우에만 배포하는데 유용합니다. 작업을 실행할 수 있는 사람을 제한하는 방법이 있으므로, 앞의 예제를 계속하기 위해 신뢰할 수 있는 사람만 배포하도록 할 수 있습니다.

작업은 또한 사용자가 다운로드할 수 있는 아티팩트를 빌드할 수 있습니다. 예를 들어 다운로드하고 기기에서 테스트할 수 있는 APK가 생성됩니다. 이러한 방식으로 디자이너와 테스터 모두가 개발자에게 도움을 요청할 필요 없이 애플리케이션을 다운로드하고 테스트할 수 있습니다.

아티팩트를 만드는 것 외에 작업은 일반적으로 사용자가 커밋을 테스트할 수 있는 URL로 연결할 수 있는 환경을 배포할 수 있습니다.

작업 상태는 스테이지 상태와 동일합니다. 실제로 스테이지는 작업에서 상태를 상속합니다.

Artifacts

앞서 말했듯이, 작업은 사용자가 테스트하기 위해 다운로드할 수 있는 아티팩트를 생성할 수 있습니다. Windows용 애플리케이션, PC에서 생성된 이미지 또는 Android용 APK 등 무엇이든 될 수 있습니다.

따라서 당신은 디자이너이고 병합 요청(Merge Request)이 할당되었으므로, 새 디자인의 구현을 확인해야 합니다!

하지만 어떻게 해야 할까요?

그림과 같이 병합 요청을 열고 아티팩트를 다운로드해야 합니다.

모든 파이프라인은 모든 작업에서 모든 아티팩트를 수집하고, 모든 작업에는 여러 아티팩트가 있을 수 있습니다. 다운로드 버튼을 클릭하면 원하는 아티팩트를 선택할 수 있는 드롭다운이 나타납니다. 검토 후 MR에 댓글을 남길 수 있습니다.

병합 요청이 열려 있지 않은 파이프라인에서 항상 아티팩트를 다운로드할 수도 있습니다. ;-)

일반적으로 테스터, 디자이너 및 이해관계자가 워크플로우에 들어가기 때문에 병합 요청에 초점을 맞추고 있습니다.

그러나 병합 요청은 파이프라인에 연결되지 않습니다. 서로 잘 통합되지만 어떠한 관계도 없습니다.

Environments

비슷한 방식으로 작업은 무언가를 외부 서버에 배포할 수 있으므로 병합 요청 자체를 통해 도달할 수 있습니다.

보시다시피 환경(Environment)에는 이름과 링크가 있습니다. 링크를 클릭하기만 하면 배포된 애플리케이션 버전으로 이동할 수 있습니다(물론, 팀에서 올바르게 설정한 경우).

GitLab에는 모니터링과 같은 환경에 대한 다른 멋진 기능도 있기 때문에 환경 이름을 클릭할 수도 있습니다.

결론

이 글은 GitLab CI의 일부 기능에 대한 간단한 소개였습니다. 매우 강력하며 올바른 방식으로 사용하면 모든 팀이 하나의 도구만 사용하여 계획에서 배포까지 이동할 수 있습니다. 매달 많은 새로운 기능이 도입되므로 GitLab 블로그를 주시하십시오.

설정 또는 고급 기능에 대해서는 설명서를 참조하십시오.

fleetster에서는 테스트 실행뿐만 아니라 소프트웨어의 자동 버전 관리 및 테스트 환경에 자동 배포를 위해 사용합니다. 다른 작업도 자동화했습니다(앱을 빌드하고 Play 스토어에 게시하는 등).

작성자 정보

Riccardo는 fleetster에서 대학생이자 파트타임 개발자입니다. 대학이나 직장으로 바쁘지 않을 때는 오픈 소스 프로젝트에 기여하는 것을 좋아합니다.

지속적 통합에 대한 소개는 원래 rpadovani.com에 게시되었습니다.

GitLab 원문 보기