
현대 소프트웨어 개발에서, 효율적인 CI/CD 파이프라인을 구축하는 것은 필수불가결한 과제이다. 이를 위해 가장 강력하게 추천하는 도구들 중 하나가 바로 ‘GitLab Runner’ 이다. GitLab Runner는 분산 빌드 환경, 유연한 설정, 안정성과 확장성, 다

앞서 작성한 글에 이어, yml파일 작성하는 방법을 알아보도록 합시다!해당 문서(https://docs.gitlab.com/ee/ci/yaml/index.html– 다음은 build를 위한 yml 예시 파일입니다.위의 설정으로 파이프라인 생성시, 정상적으로 b

앞서 진행한 build에 이어, 테스트를 위해 활용할 프로젝트의 repository에서 생성된 결과물을 활용하는 방식에 대해 알아봅시다~.~\*\*다음의 내용은 테스트를 위해 활용할 프로젝트의 repository에서 진행합니다.러너의 등록 방식은 위와 동일하며, 같은

개발과 배포의 복잡성을 극복하고자하는 현대 소프트웨어 개발자들에게는 젠킨스가 필수적인 툴로 부각되고 있다. 젠킨스는 자동화된 빌드, 테스트, 배포 프로세스를 통해 개발 생산성을 향상시키고 안정적인 개발 환경을 조성하는 강력한 솔루션이다. 이 블로그 글에서는 젠킨스의 설

해당 글에서는 빌드와 테스트를 자동화하는 파이프라인을 구축함으로써 개발자들이 복잡한 작업을 더욱 더 간편하게 수행할 수 있는 기회를 제공합니다. GitLab의 협업 기능과 젠킨스의 자동화 능력이 결합하여 현대적인 소프트웨어 개발 환경을 실현하고 더 나은 결과를 도출하는

이번 글에서는 개념을 실제로 구현하는 핵심적인 단계로 나아갑니다. 기본적인 젠킨스 파이프라인 작성 예시를 소개합니다. 이를 통해 젠킨스의 강력한 기능을 활용하여 빌드 및 테스트를 자동화하는 방법을 실제 예시와 함께 확인해보세요.Repository가 private인 경우

앞서 다룬 기본적인 파이프라인 작성 방법에 이어, 이번 글에서는 ‘artifact’ 생성에 초점을 맞춥니다. Artifact는 빌드된 결과물을 의미하며, 파이프라인 내에서 어떻게 생성하고 활용하는지 살펴보겠습니다. 이를 통해 코드의 효율적인 관리와 배포 전략을 구축하는

이전 글에서 구축한 뛰어난 artifact 생성 방법에 이어, 이번에는 그러한 artifact를 다른 파이프라인에서 손쉽게 활용하는 방법을 알아보겠습니다. 생성된 artifact를 효과적으로 공유하고 재사용함으로써 프로젝트의 효율성을 한 단계 업그레이드할 수 있는 방법

GitLab Runner와 Jenkins, 각자의 독특한 장점을 가지고 있습니다. GitLab Runner는 GitLab과의 강력한 통합으로 빌드 및 배포 프로세스를 자동화하며, 특히 CI/CD 파이프라인의 설정이 간단하고 사용자 친화적입니다. 한편, Jenkins는

GitLab CI + Fastlane + Gradle + Google Play Console 조합으로, 태그만 푸시하면 AAB 빌드와 Play 배포가 자동으로 끝나는 파이프라인을 정리한다.이 글은 두 가지를 동시에 담는다.