레넌의 개발 일기

라벨별로 빌드를 유발해야하는 이유 우리팀의 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 으로 들어..

젠킨스를 통해 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..

CI/CD를 알아보기에 앞서 자주 사용되는 용어들에 대해 정리하고 넘어가고자 한다. 컴파일 - 프로그래머가 작성한 소스코드를 기계어로 변환하는 과정 빌드 - 소스코드 파일을 컴퓨터에서 실행할 수 있는 소프트웨어 산출물로 만드는 과정 (빌드안에 컴파일 과정이 포함되어 있다.) 배포 - 빌드의 결과물을 사용자가 접근할 수 있는 환경에 배치하는 것 일반적으로 사용하는 CI/CD의 흐름은 위의 그림과 같다. CI가 무엇인지, CD가 무엇인지 알아보자. CI - Continuous Integration 지속적 통합이라는 뜻으로, 개발을 진행하면서도 품질을 관리할 수 있도록 여러명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다. CI가 없었을 때로 돌아가보자. 옛날 개발자들..