Gitlab으로 들어가서 오른쪽 위 프로필 -> Edit profile 를 클릭한다. 1. 좌측 Access Tokens 를 클릭한다. 2. Token의 이름을 설정한다. 3. Token의 만료일을 설정한다. 빈칸으로 둘 경우 만료일 없이 생성된다. 4. 해당 Token의 권한을 선택한다. 5. 위 항목을 모두 진행하였으면 Create를 눌러 Token을 생성한다. 그러면 그림과 같이 Token이 나온다. 해당 Token은 안전한 곳에 보관해두자. 만약 해당 Token을 까먹은 경우 다시 발급해야 하며 다시 발급하면 해당 Token을 등록했던 곳은 모두 변경해야하니 꼭 저장해두자. 먼저 Jenkins 메인에서 좌측 메뉴에 있는 Jenkins 관리로 들어간다. Manage Credetials 로 들어간다...

1. 프로젝트에 빌드 시 필요한 JAR 파일이 젠킨스서버에 존재하는 지 먼저 체크한다. 없다면 JAR 파일을 온라인 환경에서 다운로드 받은 후 젠킨스 서버에 옮겨둔다. 2. 배포 서버의 방화벽 설정에 젠킨스 서버를 추가해줘야 한다. 3. pom.xml 에 아래와 같이 추가해준다. 3-1. maven.compiler.source 와 maven.compiler.target 은 프로젝트의 자바 버전과 맞는 maven plugin 을 사용하겠다고 설정하는 것이다. 프로젝트에 맞는 버전을 명시해주면 된다. 3-2. failOnMissingWebXml 은 빌드 시 Error assembling WAR: webxml attribute is required 라는 에러가 나온다면 추가해주면 된다. 3-3. reposit..

보통 실무에서 젠킨스를 사용하면 Item이 많아짐에 따라 view를 통해서 보기 용이하게 설정을 한다. 이런식으로 보통 dev 와 prod 를 나누어서 사용한다. 하지만 dev와 prod 안에서도 프로젝트가 여러개 있을 것이고 또 한 프로젝트가 여러가지로 쪼개져 있는 경우도 있기 때문에 dev 와 prod 를 구분한다 하여도 Item의 개수가 많기 때문에 보기가 힘들다. 그렇다고 프로젝트 별로 dev 와 prod view를 따로 만들자니 너무 많아진다. 가장 좋은 것은 가장 큰 틀로 dev와 prod를 나눈뒤 안에서 프로젝트 별로 나누는 것인데 안타깝게도 젠키스의 기본 설정에는 그런 것이 없다. 나는 기능 자체가 많은 사람들이 필요한 기능이라고 생각되어 이미 만들어져 있지 않을까..? 하고 검색을 시작했..

기본 명령어 command desc compile 컴파일 수행 test 컴파일 수행 후 테스트 클래스 수행 package 컴파일을 수행하고 컴파일한 소스를 packaging 양식(war or jar)에 맞춰 프로젝트 내 지정한 경로(eg.target) 디렉토리에 생성 install package 한것에 추가적으로 로컬 repository에 배포한다. deploy install 한것에 추가적으로 원격 repository(nexus)에 배포한다. clean maven build 시 생성된 모든 것들을 삭제한다. 옵션 option desc -am,--also-make 프로젝트 목록이 지정된 경우 목록에 필요한 프로젝트도 빌드하십시오. -amd,--also-make-dependents 프로젝트 목록이 지정된 경..

개발자라면 한번 쯤은 들어봤을 것이라고 생각한다. DevOps 엔지니어의 핵심 업무인 만큼 인터뷰에서도 거의 빼먹지 않고 나오기 때문에 잘 이해하고 넘어가도록 하자 서비스를 오픈하거나 뭔가 핵심 기능을 운영 서버에 배포할 때 다들 한번쯤은 기도를 해본적이 있을 것이다. 항상 기도가 통한다면 좋겠지만 열명 사람 속은 알아도 프로그램 속은 모른다고(응?) 종종 문제가 생기곤 한다. 예를 들어 어떤 프로젝트를 배포했는데 갑자기 로그인이 안된다고 생각해보자. 개발자들은 난리가 날 것이고 모든 개발자가 붙어서 이 문제를 해결하려고 할 것이다. 급한 프로젝트일수록 더욱 빠르게 문제를 수정해야만 한다. 하지만 문제점을 찾아서 수정을 했다고 해서 끝이 아니다. 수정을 했으면 다시 컴파일, 빌드, 배포하는 과정을 통해 ..

"나이틀리 빌드(Nightly Build)를 망가뜨리지 말라!" 이 말은 젠킨스가 나오기 전까지 매일 아침 테스터들을 위해 새로 빌드된 일일 제품 버전을 게시하는 소프트웨어 개발 조직의 기본 규칙이었다. 나이틀리 빌드를 망가뜨리지 않기 위해 개발자가 할 수 있는 최선의 작업은 코드를 커밋(Commit)하기 전에 로컬에서 조심스럽고 성공적으로 빌드해 테스트하는 것이었다. 단, 다른 모든 사람들의 일일 커밋 없이 혼자서 누군의 변경사항을 테스트한다는 전제로,, 이를 해결하기 위해 코스케 가와구치 라는 개발자가 지금의 젠킨스의 초기 버전인 허드슨이라는 오픈소스를 개발하였다. HTML 삽입 미리보기할 수 없는 소스 젠킨스(Jenkins)는 거의 모든 언어의 조합과 소스코드 리포지토리(Repository)에 대한..