지속적인 통합NET 프레임워크

나는 이 글을 쓰는 것이 내가 줄곧 연습하고 있다는 것을 깨달았다.2005년(15년!) 이후 순발전(특히 C#).그 동안 우리는 자연스럽게 이 플랫폼의 심각한 영향을 받았다.의 출현.NET코어는 이러한 내용을 다시 볼 수 있는 기회이자 또 다른 블로그 글의 주제가 될 것이다.이 글은 요 몇 년 동안의 성숙이 (빠른 유산을) 초래했다는 것을 보여 준다.NET Framework 플랫폼

A simple project

A more complete project

간단한 항목

우선, 이러한 원칙들이 상대적으로 간단하고 기본적으로 미완성된 것에 어떻게 응용되는지 봅시다.NET Framework 프로젝트: NetMonkey 충족, a.MailChimp API의 NET 패키지(당시 3.0 버전).필요한 사항은 다음과 같습니다.

A solution file ( NetMonkey.sln ).

A build file(NetMonkey.proj)은 MSBuild로 작성되었습니다.

A script file(build.bat)은 로컬에서 파일 생성을 수행하는 데 도움을 줍니다.

A CI configuration file ( appveyor.yml ).이 프로젝트의 나머지 부분은 인프라 시설 코드다.

마카토이사 / 그물원숭이

A.MailChimp API v3.0의 NET 패키지입니다.

솔루션

해결 방안은 Visual Studio으로 a collection of related projects을 대표한다.Visual Studio를 사용하여 로드하거나 구축할 수 있습니다(MSBuild 사용).
이 경우 솔루션의 목적은 다음과 같습니다.

은 개발자가 코드를 편집하는 입구점이다.

스크립트 생성 패키지를 구축하는 입구점입니다.이것이 바로 이 프로젝트에 실제로 두 가지 해결 방안이 있는 이유입니다.

주 솔루션 NetMonkey.sln 은 라이브러리 생성에 사용됩니다.

두 번째 해결 방안인 NetMonkey.Tests.sln 에는 관련 단원 테스트도 포함되어 있다.주 프로젝트는 이전의 해결 방안과 공유되기 때문에 이것은 개발자가 개발하도록 장려하는 해결 방안(더욱 완전함)이다.

여기서 중요한 점은 개발자들이 자주 사용하는 도구 패키지를 사용하여 개발할 수 있다는 것이다 (이 예는 Visual Studio).

파일 생성

이것은 구축의 관건으로 MSBuild에 쓰여 있다.나도 Cake, 심지어 psake을 고려할 수 있지만, 나에게 있어서 MSBuild보다 더 좋은 것은 없다.비록 이것은 후천적인 품격이지만, 그것은 절대로 자신의 블로그 게시물을 가질 만하다.동시에 관건은 다음과 같다.

인치.NET Framework 전체 구축 시스템은 MSBuild를 기반으로 하고 프로젝트 파일은 적절하고 편집 가능한 MSBuild 파일입니다. (해결 방안은 그렇지 않지만)사실상 Visual Studio를 MSBuild 프로젝트의 시각화 편집기로 볼 수 있습니다.SBuild를 사용하면 보다 긴밀하게 통합됩니다.NET Framework 플랫폼

MSBuild의 로그 기능은 매우 놀랍다(예, really).

나는 XML을 개의치 않는다.

은 어쨌든 15년 전에는 진정한 대체품이 없었다.NAnt은 IMHO의 후퇴이다.추가 정보 또한...

이 파일의 요점은 간단해 보입니다.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Rebuild" ToolsVersion="14.0">
  <ItemGroup>
    <Projects Include="NetMonkey.sln" />
  </ItemGroup>

  <Import Project="$(MSBuildProjectDirectory)\packages\Isogeo.Build.*\tools\build\Isogeo.Common.targets" />
</Project>

그것은 단지 주요 해결 방안이 NetMonkey.sln 파일이라고 말할 뿐이다.나는 내 자신의 약속을 견지하기 때문에 (나는 이런 경향이 강하다) 나는 하나의 라이브러리에서 구축의 기본 부분을 추상화할 수 있고 이 라이브러리는 많은 프로젝트에서 공유할 수 있다.단점은 모든 상황(예를 들어 웹 응용 프로그램과 본체 응용 프로그램)을 15년 동안 처리하려고 시도한 후에 공공 라이브러리가 무겁고 들어가기 어려워진다는 것이다(https://github.com/isogeo/Isogeo.Build/blob/531d173efc326afceb013a6ff841e58ffcdaff25/files/build/Isogeo.Common.targets 참조).그러나 위의 간단한 정의를 통해 다음과 같은 구축 목표를 제공합니다.

정리: 정리 생성.

이것은 보통 tmp\ 폴더를 간단하게 삭제하는 문제입니다. 왜냐하면 모든 다른 목표가 그곳에서 출력을 생성하기 때문입니다.

컴파일: 지정한 해결 방안을 컴파일합니다.

테스트: 테스트 항목.

은 더 구체적으로 말하면 제공된 해결 방안과 이름이 같지만 접미사가 .Tests.sln인 해결 방안이 존재한다면 (예를 들어 본 예에서 NetMonkey.Tests.sln) 이 해결 방안을 컴파일하고 테스트를 실행할 것이다.

은 OpenCover을 사용하여 코드 덮어쓰기를 검사합니다.

분석: 프로젝트에 대해 정적 분석을 실행합니다.

FxCop이 검출되면 legacy analysis을 실행합니다.

SonarQube 프로필이 있으면 분석을 수행합니다.

은 the cloc utility을 사용하여 통계 데이터를 수집합니다.

문서: SHFB을 사용하여 프로젝트에 대한 문서를 생성합니다(tmp\out\bin 폴더에서).

패키지: 배포 가능한 패키지를 생성합니다(tmp\out\bin 폴더에서).제공되는 솔루션 유형에 따라 다음과 같은 작업을 수행할 수 있습니다.

압축 파일.

라이브러리의 NuGet 파일(NuGet은 the dependency manager of choice on the .NET platform)입니다.

웹 응용 프로그램에 사용되는 Web Deploy 패키지입니다.

컴파일: 컴파일과 테스트가 결합된 단축키.

재구성: 조합을 정리하고 생성하는 단축키입니다.

게시: 정리, 생성, 문서, 패키지 및 분석을 조합하는 단축키입니다.

내가 한 항목에서 다른 항목으로 넘어갈 때 같은 구조를 제공하면 나의 인지적 부담을 줄일 수 있다. 나는 항상 어디서부터 시작해야 하는지 안다.또한 대부분의 도구를 사용하면 tmp\ 폴더에 있는 보고서를 생성할 수 있으며, 이러한 보고서는 다양한 선택의 플랫폼(예를 들어 AppVeyor 또는 CodeCov...)으로 전송될 수 있습니다.

스크립트 파일

스크립트 파일은 로컬에서 파일 생성을 쉽게 수행할 수 있습니다.이 가능하다, ~할 수 있다,...

MSBuild는 일반적으로 %PATH%에 없습니다.나는 이것이 하나의 특성이라고 생각한다. Windows Registry으로, 여러 버전을 설치할 수 있고, 실행할 때 필요한 버전을 동적으로 선택할 수 있기 때문이다.

고급 MSBuild 매개변수를 추가하여 생성을 개선할 수 있습니다.예를 들어, 오류가 발생할 수 있는 모든 내용을 디버깅하기 위해 a complete log of the build을 생성할 수 있습니다.

하드 의존 항목을 확인해야 할 수도 있습니다(예:.NET Framework 자체!).

배치 파일의 핵심입니다(https://github.com/mcartoixa/NetMonkey/blob/master/build.bat 참조).

PUSHD .nuget
NuGet.exe restore "packages.config" -PackagesDirectory ..\packages
POPD
msbuild.exe %PROJECT% /nologo /t:%TARGET% /m:%NUMBER_OF_PROCESSORS% /p:GenerateDocumentation="%GENERATE_DOCUMENTATION%" /fl /flp:logfile=build.log;verbosity=%VERBOSITY%;encoding=UTF-8 /nr:False

어쨌든 현재 로컬 테스트 구축: build.bat.

CI 구성 파일

오래전, 나는 CruiseControl.NET으로 나의 프로젝트를 구축했는데, 그것은 나를 위해 매우 잘 서비스되었다.현재 클라우드에는 AppVeyor과 같은 더 실용적인 옵션이 많이 있습니다.NET는 여러 해 동안 통합되었습니다.나는 불가피하게 어느 순간에 변화를 일으켰다.
하지만 제 구축은 어떠한 CI 플랫폼과도 무관하기 때문에 전환이 매우 간단합니다.이것은 나의 YAML을 매우 간단하게 한다. (스스로 https://github.com/mcartoixa/NetMonkey/blob/master/appveyor.yml을 검사한다.) 나는 Azure DevOps으로 쉽게 다시 전환할 수 있다. 예를 들어.
CI 플랫폼에 해당하는 build.bat을 구성합니다.패키지(AppVeyor speak의 부품)와 버전 처리만 추가되었습니다.모든 패키지가 하나의 폴더로 출력됩니다 (일반적으로 tmp\ou\bin\). 구성은 여전히 간단합니다.

artifacts:
  - path: tmp\out\bin\*.nupkg
    type: NuGet
  - path: tmp\out\bin\*.zip

그래서 그것은 주로 발표에 관한 것이다.

더욱 완전한 항목

GeoSIK에 대해 알고 있습니다. 이것은 OGC Web Services의 개발을 간소화하기 위한 라이브러리입니다.순액이 라이브러리는 이러한 서비스를 실현하거나 외부 지리 공간 라이브러리와 통합하는 데 사용되는 11개의 라이브러리를 제공한다(예를 들어 ProjNet의 Sql Server Spatial Data types).

마카토이사 / GeoSIK

GeoSIK는 에서 OGC 웹 서비스를 개발하는 데 도움을 주는 라이브러리입니다.순액

비록 이 프로젝트는 훨씬 복잡하지만, 그것의 구조는 같다.만약 네가 위의 이 간단한 프로젝트의 구조를 이해한다면, 너는 지금 이 프로젝트를 깊이 연구하는 데 너무 많은 문제가 있어서는 안 된다.유일한 주요 변화는 간단함을 유지하기 위해 모든 라이브러리를 하나의 단일 해결 방안으로 구축하기로 결정했다는 것이다.이것은 특정한 포장 시스템이 필요하기 때문에 GeoSIK.proj (https://github.com/mcartoixa/GeoSIK/blob/master/GeoSik.proj)은 좀 복잡하다.
나에게 있어서, 이것은 비록 그것이 약속에 심각하게 의존하지만, 이 구축 시스템은 여전히 매우 강한 적응성을 가지고 있음을 나타낸다.사실상 전체 시스템은 다른 플랫폼에 적응할 수 있다.