1.배경을 소개한다
Git은 일반적으로 프로젝트 개발 중에 프로젝트를 관리하는 데 사용됩니다.
Git은 여러 사람이 함께 프로젝트를 개발할 때 더욱 중요합니다.
프로젝트는 상대적으로 비공개이고 공개할 수 없기 때문에 프로젝트 팀은 GitLab의 개인 서버를 사용하고
모두가 개발 브랜치에서 개발합니다. (때때로 독립 브랜치가 필요한 경우도 있음) )
개발이 완료되면 먼저 직접 테스트해보고, 기본적인 문제가 없다면 테스트 브랜치에 제출하세요.
1.1 이전 프로세스
- 프런트엔드 수동 패키징 - 테스트 서버에 로그인 - tomcat 또는 nginx 디렉토리에 제출
- 백엔드 수동 패키징 - 테스트 서버에 로그인 - 원본 프로젝트 중지 - 디렉터리에 제출 - 프로젝트 실행
이 과정을 여러 번 반복하다 보면 매우 번거롭고 때로는 패키징이 실패하고 코드가 업데이트되지 않기
때문에 이 부분을 기계로 교체해야 하는데 여기서는 프로젝트 통합을 돕기 위해 Jenkins가 선택되었습니다.
1.2 현재 프로세스
- 프런트 엔드는 개발 브랜치 개발이 완료된 후 테스트 브랜치에 제출됩니다.
- 백엔드는 dev 브랜치 개발이 완료된 후 테스트 브랜치에 제출됩니다.
모든 후속 작업은 Jenkins에게 넘겨집니다.
1.3 통합 프로세스
- Git 저장소에서 지정된 분기를 가져옵니다.
- 해당 버전 전환(Node, Java)
- 코드 종속성 확인
- 프로젝트 패키징
- Dockerfile 실행
- Docker 이미지를 Harbor에 제출
- Rancher에게 프로젝트 업데이트를 알리세요.
- 정적 코드 스캔
- 이슈 스캔 보고서 및 결과
- 통합이 완료되었음을 PingCode(Agile Platform)에 알림(브랜치 상태 및 배포 상태 포함)
- CI/CD 완료 이메일 알림(현재 꺼져있어 너무 귀찮음)
현재 기사에서는 프로젝트 패키징만 다룹니다.
나머지 단계는 다른 문서에 있습니다.
1.4 현재 결과
현재 많은 프로젝트가 Jenkins에 의해 관리되고
있으며 그 뒤에는 일련의 지속적인 통합 프로세스가 있습니다.결국 프로젝트는 K8s에서 실행될 것입니다(일부 작고 오래된 프로젝트는 여전히 docker-compose에 의해 관리됩니다).다음
은 이미 많은 프로젝트가 있음을 보여주는 Jenkins를 통한 프로젝트 보기.
1.5 전제 조건
귀하의 환경에 이미
- 젠킨스
- GitLab
- 프로젝트 브랜치
2. 서버 프로젝트 구성
먼저 서버에 로그인하고 프로젝트를 저장할 폴더를 만듭니다.
파일 이름은 임의이지만 이름을 아는 것이 가장 좋습니다. (제 경우에는 docker-{project name}입니다.)
여기서는 GitLab에서 직접 패키징한 스캐폴딩을 예로 들어보겠습니다(SpringBoot 프로젝트).
test-template이라는 새 프로젝트를 생성했습니다.
이 프로젝트는 백엔드 프로젝트이므로 test-template 아래에 백엔드 폴더를 새로 생성했습니다.
사용비밀번호현재 경로를 기록하는 명령
当前的路径是：/home/test-template/backend
이 폴더에는 GitLab 프로젝트의 소스 코드가 포함됩니다.
3.Jenkins 프로젝트 구성
3.1 새로운 프로젝트
Jenkins에 로그인하고 다음을 선택하세요.새로운 물품
3.2 정보 입력
프로젝트 이름은 지금 폴더에 있는 test-template-backend 규칙으로,
이 프로젝트의 백엔드로 식별됩니다
.좋아요
3.3 구성 설명
채우다설명
프로젝트에 대한 설명은 유지 관리를 용이하게 하기 위해 가능한 한 자세할 수 있습니다
.고급의
3.4 구성 폴더
고급을 클릭하면
다음과 같은 팝업이 뜹니다예배 규칙서
서버에 방금 기록된 디렉토리를 입력하세요.
3.5 Git 주소 가져오기
GitLab 프로젝트 주소를 구성합니다
. 주소는 다음과 같아야 합니다..git결정적인
3.6Git 브랜치
소스 코드를 가져오도록 분기를 구성합니다. 여기서 구성은 다음과 같습니다.*/시험
3.7 WebHook 켜기
확인하다:GitLab에 변경 사항이 푸시되면 빌드하세요...
웹훅 URL 복사: http://172.16.1.150:10101/project/test-template-backend (각 프로젝트는 다릅니다!!!)
다음 인터페이스가 나타납니다
.고급의세부 구성하기
3.8 구성 분기
Listening Branch를 선택하기 위해 여기서는 Regular Matching을 선택했습니다..*시험나뭇가지
3.9 비밀 키 구성
딸깍 하는 소리생성하다생성하다비밀토큰
3.10 스크립트 실행
선택하다짓다
딸깍 하는 소리쉘 실행쉘 스크립트를 실행하려면
여기에는 몇 가지 옵션이 있습니다
- 프로젝트에 Shell을 넣고 프로젝트를 따라가보세요(언제든지 Shell을 제출하고 수정할 수도 있다는 장점이 있습니다)
- 쉘을 서버에 올려놓는다(안전브랜치를 건네준 사람은 패키징된 명령어를 수정할 수 있는 권한이 없다는 장점이 있다)
- Shell은 Jenkins에 배치됩니다. (서버 조작이 불편한 사람도 실행할 명령어를 조작할 수 있다는 장점이 있습니다.)
3.11 작성 지침
실행하려는 Shell 명령을 입력합니다.
서비스를 중지했다가 다시 시작해야 하므로
먼저 서비스를 종료한 다음 java -jar을 실행해 볼 수 있습니다.
여기서 제 계획은 후속 작업에서 이를 Docker로 패키징하고 그런 다음 프로세스에 따라 K8s 클러스터로 푸시합니다.
이 단계는 직접 수행할 수 있습니다.
3.12프로젝트 저장
하단을 클릭하세요구하다
먼저 구성이 효과적인지 테스트하세요.
3.13 테스트 통합
딸깍 하는 소리지금 구축
GitLab의 프로젝트가시험지점 하! !
3.14 결과 보기
볼 수 있다#1、#2성공했습니다.
#1 #2를 클릭하여 볼 수 있습니다.
3.15 서버 보기
파일을 보면 Jenkins가 프로젝트를 중단
하고표적디렉토리도젠킨스구현하다mvn패키지된 디렉터리
4.GitLab 프로젝트 구성
GitLab 프로젝트 열기
선택설정
선택하다통합
4.1 웹훅 구성
채우다URL지금 바로 Jenkins의 Webhook 주소를
입력하세요.비밀토큰Jenkins의 버튼에 대해 생성된 비밀 키
4.2 웹훅 추가
딸깍 하는 소리웹훅 추가
4.3 테스트 알림
딸깍 하는 소리시험
선택하다푸시 이벤트
GitLab이 WebHook을 통해 Jenkins에게 정상적으로 알릴 수 있는지 확인하려면 클릭하세요.
4.4 일반 알림
보다:HTTP 200
이는 GitLab이 이제 Jenkins에게 정상적으로 알릴 수 있음을 보여줍니다.
5. 전체 테스트
이때 코드를 GitLab의 프로젝트 테스트 브랜치에 제출하면 Jenkins가 Shell에서 명령을 완료하도록
트리거하는 WebHook이 발행됩니다 . 이로써 기본 CI/CD가 완성됩니다. 보다 복잡한 통합에 대해서는 다른 기사를 확인하세요. 블로그에.