정리하며 배우다.

간혹 PC를 예약한 상태로 종료해야 하는 경우가 발생합니다. 

개발 서버같은 경우 주말에 정전 작업이 예정되어 있다거나, 하는 경우 등이죠. 

이럴 경우에 다른 작업자들의 작업이 끝날때까지 기다릴 순 없고, 

PC 및 서버를 예약 종료를 걸어두고 퇴근하기 좋습니다.

※ Windows

시작 -> 실행 -> shutdown -s -t 3600 (한시간 후 종료)

※ Linux

$ shutdown -h +10 (10분후 종료)
$ shutdown -t +100 (100초후 종료)

시나리오 테스트?

게임 서버를 개발 중에 있어, 현재의 고민은 최대한 문제 없이 서버를 오픈하기 위한 여러가지 방법을 도입하고, 팀원들과 연구하고 있습니다.

그 중 한가지가 개발중인 컨텐츠와 기존에 개발되었던 시스템간에 문제가 없는지를 상시적으로 테스트 할 수 있는 방법론들을 찾아서 도입하고 있는데요. 

그래서 생각해 낸 방법이, 여러 상황에 대한 시나리오를 작성하고, 정해진 시나리오 대로 서버 패킷 들을 테스트 하는 방법이 좋겠다라는 생각에 도달하였습니다. 

이 외적으로 단위 테스트도 도입하였는데요. 해당 이야기는 다음에 정리하겠습니다.

시나리오를 정해서 테스트 한다라는 개념은, 어느정도 많이 알려진 개념이였지만 BDD라는 개발 방법론으로 정리가 되어있었다는 것은 이번에 알게 되어 같이 정리해보려고 합니다. 

BDD 란?

Behavior-driven development 의 약자로 동작 지향 개발, 행동 기반 개발의 의미인 프로그램 개발 방법의 일종입니다. 

이는 테스트 주도 개발 (TDD) 에서 파생되어진 개념입니다.

BDD는 2003년 Dan North 에 의해 처음 개념이 언급되었고, 이후 TDD 지지자들의 성원 속에 스토리(시나리오) 테스트의 자동화라는 형태로 지원 프레임워크가 속속 등장하게 된다.

꽤 오래전에 언급된 개념인데, 일반적으로 생각할 수 있는 개념인데 이렇게 정형화되어서 정리가 된 방법론인지는 이제야 알게됬다.

https://dannorth.net/introducing-bdd/

BDD는 함수 단위 테스트를 권장하지 않고, 시나리오 기반으로 테스트 케이스를 작성한다. 이 시나리오는 개발자가 아닌 사람이 봐도 이해할 수 있는 수준으로 갖성되어야 하고,

하나의 시나리오는 Given, When, Then 구조를 가지는 것을 기본 패턴으로 권장한다.

Feature : 테스트 대상의 기능/책임을 명시한다.

Scenario : 테스트 목적에 대한 상황을 설명한다.

Given : 시나리오 진행에 필요한 값을 설정한다.

When : 시나리오를 진행하는데 필요한 조건을 명시한다.

Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다. 

그래서 도입은??

실질적인 도입은 BDD 개념으로 시작 했지만, 위 방법론을 정확하게 따르며 구현하지는 않았습니다.

의미에 대해서는 충분히 인지를 하였고, 구체화하는 과정은 현 개발팀의 상황에 맞게 구현하는게 맞다고 생각했습니다.

개발된 모든 패킷을 검증 할 수 있는 각각의 시나리오를 작성하였으며, 해당 기능이 동작하는 Process 를 개발 하여 도입할 예정입니다. 

구현방식에 대해서는 다음에 설명하도록 하겠습니다. 

1. 현재 로컬 저장소의 http 주소 확인

$ git remote -v 
origin  http://000.000.000.000/gitserver/test.git (fetch) 
origin  http://000.000.000.000/gitserver/test.git (push)

2. 새로운 Remote 저장소의 주소로 변경

$ git remote set-url origin http://111.111.111.111/gitserver/test.git

3. 원격 저장소의 주소로 변경 되었다면, 

$ git push --mirror

혹시 이부분이 오류가 날수 있으며, 오류가 발생시에는 강제로 푸쉬 하는 옵션을 넣어준다.

$ git push --mirror --force 

확장자 csproj 파일을 열어보면 XML로 구성되어 있다.

이중 <PropertyGroup> 에 해당 하는 부분에 패키지시 포함할 파일들을 포함시킬 수 있다. 

<CopyAllFilesToSingleFolderForPackageDependsOn>
   CustomCollectFiles;
   $(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>

<CopyAllFilesToSingleFolderForMsdeployDependsOn>
   CustomCollectFiles;
   $(CopyAllFilesToSingleFolderForMsdeployDependsOn);
</CopyAllFilesToSingleFolderForMsdeployDependsOn>

<Target Name="CustomCollectFiles" BeforeTargets="CopyAllFilesToSingleFolderForMsdeploy">
<Message Text="CustomCollectFiles" Importance="high"/>
<ItemGroup>
	<_CustomFiles Include="bin\\*.xml" />
	<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
	    <DestinationRelativePath>bin\\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
	</FilesForPackagingFromProject>
</ItemGroup>
</Target>

※ 경로에 해당하는 \\ 이스케이프 문자는 실제 적용시 한개만 입력하면됩니다. 구글 Search Console 문제로 이스케이프 문자를 하나 더 기입하였습니다.

csproj 프로젝트 파일에 해당 내용을 기입한 후 MSbuild 를 이용하면,

xml 파일들을 패키징 할 수 있다. 

<MSBuild Projects="$(ProjectFile)" ContinueOnError="false" Targets="Package" roperties="Configuration=$(Configuration)" >

참고 자료

https://stackoverflow.com/questions/23681534/asp-net-webapi-publish-xml-files-not-copy

01. 젠킨스를 Windows 에 설정하는 방법

1. Jenkins 공식 홈페이지 접속합니다. https://jenkins.io/

2. 다운로드 페이지로 바로 접속 하셔도 됩니다. https://jenkins.io/download/

3. 다운로드 페이지 접속하시면, 아래와 같은 화면을 보실 수 있습니다. ( 2018년 10월 기준 )

LTS 와 Weekly 두개의 다운로드 구분이 이루어 지는데요. 

안정적인 버전을 원하시면, 오랜시간 지원을 받은 LTS Release 를 다운받아 설치하시면 됩니다. 

Weekly는 주 단위 버그 픽스 버전입니다. 

4. 압축 파일을 푼 다음, 실행 파일을 실행합니다. 

Next -> Install -> Finish

    http://localhost:8080

6. 최초 Jenkins 웹사이트 접속시, PlugIn 을 설치하는 화면이 나오며, 필요한 Plugin을 설치하면 됩니다. 

END

프로젝트 초기에 구성했던 젠킨스에 관련해서 간단하게 정리해봅니다.

1. 젠킨스를 왜 선택하게 되었고, 

2. 어떻게 구성 하였으며, 

3. 얼마나 업무 효율이 향상되었는지

프로젝트를 진행하다 보면, 실무적으로 지속적으로 문의오는 내용이 있습니다. 

혹시.. 지금 빌드를 뽑아주실 수 있나요?

현재 적용되어 있는 빌드가 최신 버전인가요?

빌드 뽑는데 오래 걸릴까요? 바로 배포 가능하신가요?

일례적인 사례지만, 더 많은 업무요청이 있을 것으로 여겨집니다. 

형상관리 시스템 ( Git, SVN ) 을 사용하고 있었기에, 지속적으로 빌드를 생산해주고, 현재 커밋되어진 내용들에 오류가 있지 않은지 지속적으로 판단하기 위해 

CI 시스템을 구축해야 겠다고 생각했습니다. 

그 중 오픈소스이며, 가장 많이 사용되고 있는 젠킨스를 선택하게 되었으며, 

현재 프로젝트가 웹서버로 구성되고 있기 때문에, 빌드 이후 배포까지 처리하기 위해 적합하다고 판단하여 젠킨스를 도입하였습니다. 

젠킨스 개요

Jenkins는 Agile의 창시자 중 한명인 마틴 파울러씨가 주장한 지속적 통합 ( CI : Continuous Integration )을 구현하기 위한 자바 오픈 소스 소프트웨어입니다. 웹 어플리케이션 형태를 하고 있으며, 국내에서는 허드슨 (Hudson) 이라는 이름으로도 알려져 있습니다. 

2010년 오라클과의 상표권 문제로 인해 Jenkins로 이름이 바뀌게 되었습니다. 

CI (Continuous Integration) 란 무엇인가?

지속적 통합이라는 뜻으로 형상관리 시스템 (SVN or Git) 에 있는 Source 파일을 읽어들여 자동으로 빌드하여 실행할 수 있는 결과물 형태로 주기적으로 생산해주는 시스템

Jenkins가 제공하는 기능에는

• 웹 인터페이스를 통한 간편한 설정
• 강력하고 편리한 레포팅 기능
• 지속적인 자동화 빌드
• 지속적인 자동화 테스트
• 커버리지 감시
• 코드 품질 감시
• 다양한 인증기반과 결합한 인증 및 권한 관리 기능
• Groovy Script 를 이용한 고수준의 잡 스케쥴링 기능
• 커맨드라인 인터페이스 제공
• 자동화된 배포 관리
• 분산 빌드 가능
• 윈도우 커멘드 스케쥴링 실행기능

이 있다고 합니다. (출처 : More Agile)

저희가 프로젝트에 Jenkins를 도입하려 했던 이유는

1. 지속적인 자동화 빌드

2. 자동화된 배포 관리

3. 윈도우 커맨드 스케쥴링 실행 가능

위 세가지 이유로 인해서 젠킨스를 도입하였습니다.