Jenkins 및 .NET을 사용한 지속적 배포

이 블로그 게시물은 Jenkins와 Couchbase에 대한 두 개의 블로그 게시물 중 첫 번째 게시물입니다. 이 첫 번째 포스팅은 지속적 배포에 대한 일반적인 소개입니다: 를 사용하는 방법을 배우게 됩니다. Jenkins를 사용하여 .NET 애플리케이션을 자동으로 배포하는 방법을 소개합니다. 두 번째 블로그 게시물에서는 테스트 코드를 실행하기 전에 Jenkins를 사용하여 Couchbase에서 테스트 데이터를 설정하는 방법에 대해 자세히 다룰 예정입니다.

.NET 개발자는 Visual Studio를 사용하고 있을 것입니다. Visual Studio에서 F5를 누르면 소스 코드가 컴파일되고 디버거가 시작됩니다. 저와 같은 개발자라면 개발 및 버그 추적 중에 F5를 여러 번 누를 것입니다.

하지만 코드가 프라임 타임에 배포할 준비가 되면 어떻게 될까요? 배포가 시작됩니다!

애플리케이션을 게시해야 할 때는 실행 파일을 대상에 수동으로 복사하고 애플리케이션을 수동으로 설치한 후 수동으로 시작하는 가장 느린 옵션을 선택하는 경우가 많습니다.

처음 몇 번은 '재미'가 있지만 결국에는 정말 어려워지며, 특히 변경 사항을 추적하고 수동으로 업데이트/배포하는 것은 매우 어렵습니다. 솔직히 말해서, 이러한 수동 접근 방식은 확장성이 떨어지고 불필요한 시간이 소요되며 배포 과정에서 인적 오류가 발생하기 쉽습니다.

보다 성숙한 옵션은 배포를 처리할 수 있는 자동화된 인프라를 갖추는 것입니다. 이러한 인프라를 흔히 지속적 통합/지속적 배포라고 합니다.

지속적 통합/지속적 배포를 사용하면 다음과 같은 워크플로우를 사용할 수 있습니다:

• 개발 상자에서 로컬로 코딩, 빌드 및 테스트(평소와 같이)
• 자주 사용하는 소스 제어 관리 시스템에서 개발 브랜치로 소스 코드를 확인합니다.
• 팀원이 코드를 검토하는 옵션입니다.
• 변경 내용을 메인(릴리스) 브랜치에 병합합니다.
• CI 서버는 메인 브랜치에 대한 변경 사항을 감지하고 릴리스 서버에 애플리케이션을 다운로드, 컴파일 및 배포/설치합니다.

수동 단계는 없으며 모두 스크립트화되어 자동으로 이루어집니다.

지속적인 배포

여러 가지 지속적 통합/배포(CI) 도구 중에서 선택할 수 있으며, 각 도구에는 고유한 주의 사항이 있습니다. 제 설정에서는 애플리케이션의 구성 요소를 이해하는 CI 서버가 필요합니다.

이제 애플리케이션 아키텍처와 구성 요소에 대해 자세히 살펴보겠습니다:

• 플랫폼: .NET 4.5.2
• IDE: Visual Studio 2015(MSBuild 파일)
• 애플리케이션 유형: Windows 서비스
• NuGet: 모든 참조에 사용되는 패키지 관리자.
• 소스 제어: Git (github.com)

CI 서버는 위에서 언급한 모든 구성 요소를 이해할 수 있어야 하며, (제가 게으른 탓에) 유지 관리 및 설정이 정말 쉬워야 합니다.

약간의 조사를 해본 결과, 다른 사람들의 경험과 블로그 게시물을 통해 Jenkins를 사용하는 것이 가장 좋다는 것을 알았습니다. 를 사용하여 Windows 서비스 배포.

Jenkins

Jenkins는 플러그인 아키텍처를 갖춘 빌드 서버로, 커뮤니티가 Jenkins가 "이해할 수 있는" 것을 확장할 수 있습니다. 이 아키텍처를 사용하면 MSBuild 파일, Git 버전 관리 등을 지원하도록 Jenkins를 쉽게 확장할 수 있습니다.

젠킨스 소개

설정

Jenkins는 빌드 서버에 설치됩니다. 제 설정에서는 빌드 서버가 릴리스 서버와 동일하지만 다르게 구성할 수 있습니다.

다운로드 및 설치 플랫폼용 젠킨스: https://jenkins-ci.org/

설치 후 Jenkins는 기본 포트에서 사용할 수 있습니다: http://localhost:8080/

Jenkins 구성

Jenkins에는 Git 리포지토리, MSBuild 파일 및 기타 다양한 기술을 이해하기 위한 플러그인이 있습니다. 현재 설정에서는 이 두 가지 플러그인으로 Jenkins를 확장하기만 하면 됩니다.

Jenkins용 Git 플러그인을 설치합니다:

1. Jenkins를 엽니다, http://localhost:8080/
2. "젠킨스 관리"로 이동합니다.
3. "플러그인 관리"로 이동합니다.직접 링크: http://localhost:8080/pluginManager
4. "필터" 상자를 사용하여 "Git 플러그인"을 검색하고 플러그인을 설치합니다.

Jenkins용 MSBuild 플러그인을 설치합니다:

1. Jenkins를 엽니다, http://localhost:8080/
2. "젠킨스 관리"로 이동합니다.
3. "플러그인 관리"로 이동합니다.직접 링크: http://localhost:8080/pluginManager
4. "필터" 상자를 사용하여 "MSBUILD 플러그인"을 검색하고 플러그인을 설치합니다.이제 Jenkins는 MSBuild 파일과 Git 소스 제어를 이해하지만 여전히 MSBuild 플러그인에 msbuild.exe 사용하고자 합니다.

MSBuild 구성

MSBuild 플러그인을 설치하면 Jenkins 전역 구성 페이지에 자체 구성 옵션이 추가됩니다.

1. 다음으로 이동합니다. http://localhost:8080/
2. "젠킨스 관리"를 클릭합니다.
3. "시스템 구성"을 클릭합니다.
4. 목록을 아래로 스크롤하여 "MSBuild"를 찾습니다.
5. "MSBuild 설치..." 버튼을 클릭합니다.
6. "MSBuild 추가"를 클릭합니다.
7. 새 MSBuild 구성에 "MSBuild-default"와 같은 이름을 지정합니다.
8. 경로 필드에 다음에 대한 정규화된 경로를 입력합니다. msbuild.exe내 서버의 경로는 다음과 같습니다: C:프로그램 파일 (x86)MSBuild14.0Binmsbuild.exe하지만 시스템에 따라 다를 수 있습니다.아래에서 MSBuild 및 설치 방법에 대한 자세한 내용을 확인하세요.
9. 저장을 클릭합니다.

MSBuild 설치

MSBuild는 Visual Studio와 함께 설치되며, Visual Studio에서 "빌드"를 선택하거나 "F5"를 누를 때 사용하는 빌드 시스템입니다.

빌드 머신에 Visual Studio를 설치하는 것이 항상 가능하거나 가능하지 않은 경우도 있습니다. 라이선스 및 보안 문제 등이 원인일 수 있습니다.

이를 위해 Microsoft는 별도의 패키지를 출시했습니다: "Microsoft 빌드 도구 2015"라는 별도의 패키지를 출시했는데, 이 패키지에는 MSBuild 사용에 필요한 모든 것이 포함되어 있습니다.

직접 다운로드: https://www.microsoft.com/en-us/download/details.aspx?id=48159

설치가 완료되면 빌드 서버에서 MSBuild를 사용할 수 있으며 위의 8단계에 대한 경로 값을 얻게 됩니다.

이 단계가 완료되면 Jenkins는 MSBuild 및 Git으로 빌드 및 배포할 준비가 된 것입니다.

새 Jenkins 빌드 프로젝트 만들기

이제 Jenkins에게 소스 코드를 가리키고 빌드를 시작할 차례입니다.

1. Jenkins를 엽니다, http://localhost:8080/
2. "신규".직접 링크를 선택합니다. http://localhost:8080/view/All/newJob
3. 프로젝트의 이름을 "Windows 서비스 배포" 또는 기억하기 쉬운 이름으로 지정하세요.
4. "프리스타일 프로젝트"를 선택합니다.
5. "확인"을 선택합니다.
6. 다음으로 'Git'을 선택하여 '소스 코드 관리' 영역을 확장합니다.
7. 리포지토리에 대한 URL과 필요한 경우 자격 증명(선택 사항)으로 빈칸을 채워 Git 구성을 완료하고, Jenkins는 브랜치에서도 작업할 수 있습니다. 이 설정에서는 브랜치를 기본값(마스터)으로 두지만 필요에 따라 원하는 것을 선택할 수 있으며, 테스트용 Git 리포지토리가 아직 준비되지 않은 경우 여기에서 미리 준비된 리포지토리를 사용할 수 있습니다:https://github.com/martinesmann/jenkins-ci-template소스 코드에는 일반적인 "Hello Windows 서비스" 솔루션보다 몇 가지 파일이 더 포함되어 있습니다. 관련 부분은 나중에 사용하면서 설명하겠습니다. 지금은 그냥 "Hello World" 솔루션으로 취급하겠습니다.
8. 아직 저장하지 않았다면 '저장'을 클릭하여 변경 사항을 유지하고 기본 '프로젝트' 페이지로 돌아갑니다.

Git 구성 테스트

이제 Git 소스 관리 탭이 올바르게 구성되었는지, 소스 코드를 복제할 수 있는지 테스트할 수 있습니다.

아직 아무것도 구축하지 않고 소스만 복제하고 있습니다. 빌드는 곧 시작될 것입니다. 먼저 Jenkins가 리포지토리에서 소스를 복제할 수 있는지 확인해 보겠습니다.

1. '프로젝트' 페이지로 이동합니다.
2. '지금 빌드'를 클릭하여 '빌드'를 시작합니다.
3. 이제 '빌드 기록' 영역에서 "#1"이라는 이름의 빌드가 진행 중임을 확인할 수 있습니다.
4. 예상대로 모두 "성공"으로 완료되면 버블 메이커는 파란색으로 유지되고, 그렇지 않으면 빨간색으로 바뀝니다.
5. 빌드 세부 정보를 보려면 빌드 번호 "#1"을 클릭하세요.
6. 그런 다음 "콘솔 출력"을 클릭합니다. 여기와 비슷한 내용이 표시될 것입니다:
   
   Started by user anonymous Building in workspace C:Program Files (x86)JenkinsjobsWindows Service deploymentworkspace Cloning the remote Git repository Cloning repository https://github.com/martinesmann/jenkins-ci-template > git.exe init C:Program Files (x86)JenkinsjobsWindows Service deploymentworkspace # timeout=10 Fetching upstream changes from https://github.com/martinesmann/jenkins-ci-template > git.exe --version # timeout=10 > git.exe -c core.askpass=true fetch --tags --progress https://github.com/martinesmann/jenkins-ci-template +refs/heads/*:refs/remotes/origin/* > git.exe config remote.origin.url https://github.com/martinesmann/jenkins-ci-template # timeout=10 > git.exe config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > git.exe config remote.origin.url https://github.com/martinesmann/jenkins-ci-template # timeout=10 Fetching upstream changes from https://github.com/martinesmann/jenkins-ci-template > git.exe -c core.askpass=true fetch --tags --progress https://github.com/martinesmann/jenkins-ci-template +refs/heads/*:refs/remotes/origin/* > git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10 > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10 Checking out Revision db11bee4586694774f21e9f38b57af8535c88e1e (refs/remotes/origin/master) > git.exe config core.sparsecheckout # timeout=10 > git.exe checkout -f db11bee4586694774f21e9f38b57af8535c88e1e First time build. Skipping changelog. Finished: SUCCESS

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   시작됨 by 사용자 익명 빌딩 in 작업 공간 C:프로그램 파일 (x86)젠킨스채용윈도우 서비스 배포워크스페이스 복제 의 원격 Git 저장소 복제 저장소 https://github.com/martinesmann/jenkins-ci-template > git.exe init C:프로그램 파일 (x86)젠킨스채용윈도우 서비스 배포워크스페이스 # 시간 초과=10 가져오기 업스트림 변경 사항 에서 https://github.com/martinesmann/jenkins-ci-template > git.exe --버전 # 시간 초과=10 > git.exe -c 핵심.askpass=true fetch --태그 --진행 상황 https://github.com/martinesmann/jenkins-ci-template +refs/heads/*:refs/remotes/origin/* > git.exe 구성 원격.원산지.URL https://github.com/martinesmann/jenkins-ci-template # timeout=10 > git.exe 구성 --추가 원격.원산지.fetch +refs/heads/*:refs/리모컨/원산지/* # 시간 초과=10 > git.exe 구성 원격.원산지.URL https://github.com/martinesmann/jenkins-ci-template # timeout=10 가져오기 업스트림 변경 사항 에서 https://github.com/martinesmann/jenkins-ci-template > git.exe -c 핵심.askpass=true fetch --태그 --진행 상황 https://github.com/martinesmann/jenkins-ci-template +refs/heads/*:refs/remotes/origin/* > git.exe rev-parse "참조/리모트/원본/마스터^{커밋}" # 시간 초과=10 > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # 시간 초과=10 확인 out 개정 db11bee4586694774f21e9f38b57af8535c88e1e (refs/리모컨/원산지/마스터) > git.exe 구성 핵심.스파 체크아웃 # 시간 초과=10 > git.exe 결제 -f db11bee4586694774f21e9f38b57af8535c88e1e 먼저 시간 빌드. 건너뛰기 변경 로그. 완료: 성공

   
   *여기서 주목해야 할 점은 경로 를 '워크스페이스'에 추가하면 소스 코드가 다운로드되고 빌드되는 곳입니다. 이 지식은 CI 설정을 디버깅할 때 매우 유용할 수 있습니다*.

소스 구축

다음 단계는 소스 코드를 컴파일하고 빌드하는 것입니다.

1. '프로젝트' 페이지로 이동합니다.
2. "구성"을 선택합니다.
3. "빌드 단계 추가" 찾기
4. "MSBuild를 사용하여 Visual Studio 프로젝트 또는 솔루션 빌드"를 선택합니다. 여기서 몇 가지 값을 구성해야 합니다:
   1. 먼저 MSBuild 버전을 선택합니다(이전 단계에서 구성했습니다).
   2. 그런 다음 프로젝트의 *.sln 또는 *.proj 파일 경로를 지정합니다.미리 준비된 리포지토리의 경우 경로는 다음과 같습니다: srcMyWindows서비스MyWindows서비스배포-윈도우 서비스-Via-MSBuild.proj참고 사항: 솔루션 파일을 가리키는 것이 아니라 프로젝트에 있는 사용자 지정 MSBuild 파일을 가리키고 있습니다. 이 MSBuild 파일은 Windows 서비스 컴파일 및 배포와 관련된 모든 단계를 처리합니다.미리 준비된 리포지토리를 사용하는 경우 설정은 다음과 같아야 합니다:
   3. 저장을 클릭합니다.

NuGet 패키지 복원

지금 프로젝트를 빌드하면 누락된 NuGet 패키지로 인해 실패할 것입니다. 따라서 소스를 빌드하기 전에 NuGet 패키지를 복원해야 합니다.

nuget.exe 를 사용하면 이 작업이 매우 쉬워지므로 솔루션 파일에서 이 명령을 실행하기만 하면 됩니다:

너겟 복원 "*.sln" 파일 경로

Jenkins가 여러 빌드 단계를 처리할 수 있는 것은 당연하므로 NuGet 복원을 사용하도록 빌드 단계를 추가해 보겠습니다.

1. '프로젝트' 페이지로 이동합니다.
2. '구성'을 선택합니다.
3. '빌드 단계 추가'를 찾습니다.
4. '빌드 단계 추가'를 클릭합니다.
5. "Windows 배치 명령 실행"을 선택합니다.
6. 새 빌드 단계를 맨 위로 드래그하여 빌드 순서를 다시 정렬합니다.
7. 명령 필드에 삽입합니다:너겟 복원 srcMyWindowsService
8. "저장"을 클릭합니다.

이제 프로젝트를 구축할 준비가 되었습니다!

마지막 테스트! 프라임타임!

1. 프로젝트 페이지로 이동합니다.
2. '지금 빌드' 링크를 클릭합니다.
3. 빌드가 완료될 때까지 기다립니다.
4. "Windows 탐색기"를 열고 다음 위치로 이동합니다. C:
5. "MyWindowsService.log" 파일이 존재하는지 확인합니다.
6. 파일을 열고 로그 내용을 읽어보세요.이 파일은 새로 설치된 Windows 서비스에 의해 생성되었습니다!
7. 서비스가 설치되어 실행 중인지 확인합니다:
   1. Windows에서 '서비스' 관리 창을 엽니다.
   2. 아래로 스크롤하여 "내 Windows 서비스(...)" 서비스를 찾습니다.

축하합니다! 이제 .NET Windows 서비스를 다운로드, 컴파일 및 배포하도록 Jenkins를 성공적으로 구성했습니다! 자동화가 시작되었습니다!

소스 코드입니다:

지금까지 소스 코드에는 크게 신경을 쓰지 않았지만 잠시 시간을 내어 리포지토리 콘텐츠와 구조를 살펴보겠습니다.

에서 리포지토리 루트로 이동합니다:

https://github.com/martinesmann/jenkins-ci-template

에는 README 등의 일반적인 파일뿐만 아니라 다음과 같은 파일도 있습니다. nuget.exe.

nuget.exe 은 솔루션의 NuGet 패키지 종속성을 복원하는 데 사용되는 실행 파일입니다. 소스 컨트롤에 바이너리 파일을 포함하는 것이 좋은 방법인지 아닌지에 대해 논쟁할 수 있지만 이 경우 빌드 시스템에 필요한 종속성이므로 포함했습니다.

나는 nuget.exe 를 루트에 추가하여 실제 소스 코드와 분리된 상태로 유지하고 Jenkins에서 빌드를 설정할 때 쉽게 찾을 수 있도록 했습니다.

리포지토리로 더 깊이 들어가면 다음과 같이 표시됩니다. src/MyWindows서비스/MyWindows서비스/ 에서 Windows 서비스를 컴파일하고 설치하는 모든 작업을 수행하는 네 개의 파일을 찾습니다.

기본 진입점 파일은 다음과 같습니다. 배포-윈도우-서비스-비아-엠에스빌드.proj 소스 코드를 컴파일할 뿐만 아니라 Windows 서비스 애플리케이션을 중지, 제거 및 시작하도록 구성된 MSBuild 파일입니다. 이 작업은 필요에 따라 세 개의 배치 파일을 호출하여 수행합니다: safeServiceDelete.bat, safeServiceStart.bat 그리고 safeServiceStop.bat.

이 블로그 게시물에서 네 가지 파일 각각이 하는 일을 자세히 설명하는 것은 범위를 벗어난 것이지만, 파일을 하나씩 살펴본다면 파일의 내부 작동 방식과 협업 방식을 잘 이해할 수 있을 것입니다.

Windows 서비스 소스 코드는 Visual Studio에서 특정 요구 사항에 맞게 보고 편집할 수 있습니다. 리포지토리에 제공된 샘플 소스는 매우 간단하며 텍스트 파일(로그 파일)에 몇 개의 항목만 쓰고 Couchbase Server에 문서를 '업서트'합니다:

Service1.cs

Couchbase를 처음 사용하는 경우 여기에서 .NET 튜토리얼을 살펴보는 것이 좋습니다:

try-cb-dotnet.

나만의 콘텐츠 만들기

가장 쉬운 방법 젠킨스 및 .NET을 사용하여 빌드 및 배포하기 자동화된 Windows 서비스를 만들려면 이 리포지토리를 복제하고 Visual Studio에서 필요에 맞게 서비스 코드를 변경하는 것이 가장 좋습니다.

읽어 주셔서 감사합니다!