레넌의 개발 일기

라벨별로 빌드를 유발해야하는 이유 우리팀의 Github 레포지토리는 백엔드와 프론트 파일을 함께 관리하고 있다. 따라서 어떤 파일이 수정되었던지 간에 상관없이 Develop 브랜치와 Main 브랜치에 PR이 머지되거나 Push가되면 프론트엔드 파이프라인과 백엔드 파이프라인이 모두 돌아가 불필요한 빌드가 실행되는 경우가 있었다. PR의 라벨에 따라 파이프라인이 돌아가도록 설정한다면 이 문제를 해결할 수 있을 것이라고 판단했다. 기존 설정 파이프라인의 빌드 유발을 설정할 때 보통은 GitHub hook trigger for GITScm polling을 많이 사용할 것이다. 이 설정은 깃허브로부터 Push 훅을 받았을 때 빌드가 유발되는 설정이다. 이 설정은 위에서 설명한 문제점이 있다. 라벨별로 설정하기 P..

CI 속도를 개선해야하는 이유 CI는 지속적 통합이라는 뜻으로, 개발을 진행하면서도 품질을 관리할 수 있도록 여러명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다. 지속적으로 빌드와 테스트를 돌림으로써 통합되는 코드에 대해 문제가 없는지 확인하는 것이 CI의 중요한 요소 중 하나라고 생각한다. 따라서 빌드와 테스트에 대한 피드백 시간 또한 중요하다. 빠르게 피드백을 받게 된다면 불과 몇 초일지라도 개발자 조금이나마 편하게 개발을 진행할 수 있을 것이다. 기존의 Workflow 처음 공식 프로젝트에서 적용한 workflow 는 아래와 같다. name: gongseek backend CI # Workflow를 실행시키기 위한 이벤트 목록 # 모든 브랜치에 대한 PR이..

처음에는 CI/CD 도구로 비교적 간편한 CI/CD 도구인 Github Actions를 사용하려고 했지만, 우테코 Organization 권한 문제로 CD를 진행할 수 없었다. CI는 Github Actions로 진행하고, CD는 젠킨스로 진행하기로 했다. 간단하게 Github Actions에 대해 알아보려고 한다. Github Actiosn에서는 특정 레포지토리에 대한 PullRequest가 열리거나 Issue가 열리는 등의 이벤트가 트리거 되도록 workflow를 구성할 수 있다. workflow에는 1개 이상의 순차적으로 실행되거나 병렬적으로 실행되는 jobs를 포함할 수 있다. 각각의 job은 자체 virtual machine runner나 컨테이너 내부에서 실행된다. 구성요소 WorkFlow w..

문제점 Jenkins 파이프라인을 작성하다가 Host key verification failed 문제를 맞이했다. 처음에 작성한 파이프라인은 아래와 같다. pipeline { agent any stages { stage('Checkout SCM') { steps { checkout([$class: 'GitSCM', branches: [[name: '*/develop']], extensions: [[$class: 'SubmoduleOption', disableSubmodules: false, parentCredentials: true, recursiveSubmodules: true, reference: '', trackingSubmodules: true]], userRemoteConfigs: [[crede..

이전 게시글에서는 백엔드 파이프라인을 구성하는 방법에 대해서 이야기 해보았다. 이번에는 프론트엔드에서는 어떻게 파이프라인을 구성할 수 있을 지에 대해 알아보도록 하자. 파이프라인을 구축하기 전까지의 단계인 깃헙 토큰 설정, 웹훅 설정, Credentail 설정은 백엔드편과 동일하기 때문에 생략하도록 하겠다. (사실 파이프라인 과정도 크게 다르지 않다.) 설정 우리팀의 프론트에서는 리액트를 사용하고있다. 이를 빌드하기 위해서는 서버에 Node.js가 서버에 깔려있어야한다. 이를 위해 Jenkins에서 미리 설정을 해주어야한다. 이를 위해서 젠킨스에 NodeJS 플러그인을 따로 설치해주었다. NodeJS 플러그인이 설치되었다면, Jenkins관리 -> Global Tool Configuration 으로 들어..

젠킨스를 구축하는 과정에서 빌드를 끝마치지 못하고 서버가 죽어버리는 현상이 발생했다. 처음에는 무슨 문제인지 인지하지 못하였고 서버를 껐다 켜보기만을 반복하였다. Gradle 빌드의 문제인 줄만 알고 빌드의 속도나 의존성을 계속 봤었다. 하지만, 문제는 코드에 있지 않았다. 바로 메모리가 부족하기 때문에 발생한 일이었다. 우아한테크코스에서 제공해주는 인스턴스는 t4g.micro이다. 그렇기에 Memory는 1GB 밖에 되지 않았다. 1GB는 젠킨스 위에서 빌드를 돌리기에는 턱 없이 부족했던 것 같다. 따라서 이 문제를 해결하기 위해서 Swap Memory라는 것을 이용하였다. Swap Memory란? 실제 메모리가 가득 찼는데 더 많은 메모리가 필요로 할 때, 하드디스크의 공간을 가상 메모리로 대체하여 ..

젠킨스를 통해 CI/CD 파이프라인을 구축해보자. Jenkins의 Item FreeStyle vs Pipeline FreeStyle 방식은 진입 장벽이 낮고 기존 사용 사례가 많아서 참고할 자료가 풍부하다는 장점이 있다. 하지만 젠킨스 플러그인을 이용한 커스터마이징이 제한적이고, 테스트 혹은 빌드 등의 작업에서 병렬처리를 미지원한다는 점과 다수의 형상관리 Repository와 연계하여 사용할 수 없다는 단점이 있다. Pipeline 방식은 FreeStyle 방식에 비해 진입장벽이 비교적 높고 기존 사용 사례가 적어 참고할 자료가 많이 없다는 단점이 있다. 하지만 커스터마이징의 폭이 넓고 테스트 혹은 빌드 등의 작업에서 병렬 처리를 지원하다는 점과 다수의 형상관리 Repository와 연계하여 사용할 수 ..

자바 설치 sudo apt install openjdk-11-jre jenkins는 자바 기반으로 돌아가기 때문에 자바를 필수적으로 설치해주어야한다. 설치 CLI wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add - sudo sh -c 'echo deb https://pkg.jenkins.io/debian-stable binary/ > \ /etc/apt/sources.list.d/jenkins.list' sudo apt-get update sudo apt-get install jenkins Jenkins 실행 sudo service jenkins start Jenkins 상태 확인 sudo service..