머리말

오늘, 소프트웨어 개발의 지속적인 통합은 애자일 개발도 중요한 부분이다, 표준화 된 프로세스가되었다. 소위 지속적인 통합은 가능한 한 빨리이 개발의 결과를 확인하기 위해 자동화 된 빌드 (컴파일, 게시, 자동화 된 테스트 등) 프로젝트에 제품 개발 노력을 병합합니다 정기적으로 (더 적은 매일 또는)에 소프트웨어 개발 팀 구성원을 말한다 오류 및 취약점을 찾을 수 있습니다 (이 콘텐츠 자체의 개발의 문제가있을 수 있습니다, 그것은 기존의 제품 개발 내용과 내용 사이의 호환성 문제가있을 수 있습니다).

연속 배달, 그것은 팀 또는 사용자 리뷰의 품질과 조기 프로덕션 환경에 제품 이전 가능, 위험 평가 및 문제 해결 같은 결함을 찾기 위해 테스트에 공급되는 제품의 새 버전을 지정합니다. 게임 개발 과정에서, 우리는 계획 / QA 팀이 테스트를 위해 테스트 서버를 업데이트 할 서버 / 클라이언트 최신 코드 (자원)의 성능을 제공하는 것을 계속했다.

마지막으로 연속 배치는, 평가 후 이전 단계에 의해 제공되는 코드를 참조, 자동으로 프로덕션 환경에 배포 할 수 있습니다. 그의 목표는 코드가, 당신은 생산 단계를 입력 할 수있다 한 번에 배포 할 수 있다는 것입니다. 게임 개발 과정에서 서버 / 클라이언트 코드 (자원)의 성능의 지속적인 전개 공식 서비스를 업데이트합니다.

지속적인 통합, 배달, 배포를 통해 개발 팀, 크게 기능 통합 문제를 줄이고 개발 팀의 효율성을 향상시킬 수, 팀은 고품질의 소프트웨어 제품을 개발할 수 있습니다.

연속 통합, 그래서 중요하기 때문에 왜 "블랙 드래곤"이 제품은 지속적인 통합 및 기타 관련 프로세스 그 일을하지 않았다? 프로젝트 시작부터이 역사.

프로젝트의 역사

빨리 온라인 제품이 높은 회사의 기존 사업 개발과 (종)을 평가하기 위해 2014 년 초에 블랙 드래곤 팀 프로젝트는 초기 개발에 블랙 드래곤은 힘을 위해, 제품 자체에 초점을 맞추고있다. 그러나 평화 유지 작업의 배치의 관점에서, 그것은 여전히 매우 원시적 인 방법입니다 : 수동으로 업데이트를 수동, 수동으로 패키지를 컴파일 .... 좋은 소식은 다른 비슷한 게임의 출현 이전 때문에 짧은 개발주기의 블랙 드래곤, 일본, 한국, 동남 아시아에서 "사실적인 3 개 개의 카드는"신흥 시장을 점유하고 좋은 결과를 달성 한 것입니다. 그러나, 또한 지속적인 통합 과정 포함 존중의 부족 등 만의 프로젝트 팀에 대한 질문과 많은 문제를 가져왔다.

문제

게임 제품 값은 자주 변경하지만 계획은 테스트 서버 구성 테이블을 업데이트 할 독립적 인 방법입니다. 서버 프로그래머에 그 이상의 신뢰의 효율성은 소비 구성 테이블 업데이트 시간을 증가, 구성 테이블을 업데이트하는 데 도움뿐만 아니라 심각하게 서버 프로그래머에 영향을합니다.
수동으로뿐만 아니라 많은 시간이 소요 및 오류가 발생하기 쉬운 과정을 우려, 서버 프로그래머를위한 업데이트 된 패키지를 컴파일합니다. (사고 많은 시간을 임시 유지 보수 업데이트는 코드는 컴파일되지 않고 역사적으로 블랙 드래곤의 결과가 되었기 때문에)
경우에만 연기 테스트, 블랙 박스 테스트 및 수용 업데이트 기능 때의 기능을 의존하는 자동화 된 테스트 프로세스 (단위 테스트), 및 코드의 품질을 보장 할 수 없습니다.
(정확히 같은 보장하지 않는 내용을 업데이트, 공식 서비스는 여전히 수동 지정된 위치에 업로드 업데이트, 운영 및 유지 보수 업데이트 작업에 의존 업데이트 비록 나중에 공식적인 옷과 MD5 체크섬 테스트 서버 만의 증가 아직 시간이 많이 소요 업로드 및 갱신의 과정을 힘든)
운영 및 유지 보수 요구 사항에 관련된 공식 서비스 직원을 업데이트, 개발자, 컨텐츠를 유지하기 위해 부주의 운영 및 유지 보수 인력 및 드레인 업데이트 특정 서버가 각 도킹 유지 보수 및 운영 및 유지 보수 인력에 필요합니다.

프로토 타입 : 구성 테이블 게시 도구

그래서 많은 질문 단계적으로 해결해야합니다. 이 심각하게 계획 및 서버 프로그래머의 효율성에 영향을주기 때문에 가장 기본적이고 가장 시급한 문제는, 질문 1 (갱신 계획 독립적 인 테스트 서비스 구성 테이블)입니다. 나는 드래곤 팀을 온 첫 번째 작업이 계획은 일주일 내에 업데이트 테스트 서버 구성 도구를 사용하여 테이블에 전달 될 수 개발하는 것이다 받았을 때 시간은 2016 년이었다. 서버 업데이트 프로세스를 빗질 한 후, 대략 구현 단계에 대한 처리 : 서버를 종료 원격 서버 스크립트를 호출 - 원격 부팅 서버> -> 계획 구성 테이블을 게시 할 필요가 업로드합니다. 때문에 요구 사항이 상대적으로 꽉 시간 그래서 콘솔의 한 버전, 다음 그림 :

비교적 간단하지만, 인터페이스는 매우 친절 아니지만, 기본적으로 구성 테이블을 업데이트 할 계획의 문제를 해결할 수있다. 나중에도 포장 코드, 릴리스 코드 및 기타 기능을 증가했다.

추신 : 그것은 단지 업데이트 업데이트 문제를 해결하는 도구를 수행하는 데 필요한 작업에 따라, 사고 방식 제한 할 수 있으며, 자동화 된 프로세스를 소개 젠킨스를 사용하여 생각하지 않았지만, 블랙 드래곤 완전한 지속적인 통합, 전달의 결과로, 게시 도구의 최적화 반복으로 계속 이동 지역 배포 경고를해야 더 많은 실수를 인 작업을 지연.

최적화 : 그래픽 인터페이스 버전

테스트 서비스 도구를 게시되었지만, 콘솔 창 비우호적 인 인터페이스는, 기동 할 수 있지만, 심지어는 그것에 대하여 아무것도 비교 혼자 다른 사람을하도록 할 수 있습니다. 그런 다음 계획, 절차의 다양한 요구에 대한 조사에서, 내가 개발의 GUI 버전을 시작하는 중립에서 작동하는 데 사용되는 그래픽 인터페이스 버전에 대한 아이디어가 있었다. 데스크톱 소프트웨어가 합리화에 초점을 맞추고 있기 때문에, m의 JRE 환경의 수백 그래서 개발 언어로 자바를 계속 사용할 생각을 포기하지만, 파이썬을 돌렸다. 그래픽 인터페이스 버전이 탄생 그래서 파이썬 GUI 개발 프레임 워크의 wxPython은, SSH 라이브러리 paramiko을 가지고, 윈도우 환경 패키지는 완전히 내 기대와 일치, pyInstaller 중에있다.

선택 중 JDK 경로, 자동 코드 컴파일, 패키지, 업로드, 갱신, 지속적인 통합의 기본 실현, 배달 워크 플로우에 의해 인터페이스의 버전 및 문제 2 (테스트 서버 업데이트 프로세스가 오류가 발생하기 쉬운 문제 지루) 해결한다.

코드가 GitLab에 업로드되어, 관심이 갈 수 있습니다 보기

지속적인 통합, 배달 및 배포

위의 후 연속 통합 과정으로, 나는 지속적으로 배포 작업을 수행하는 방법에 대해 생각했다, 그러나 발견은 막 다른 골목에 진입 한 것으로 보인다. 사용자 지정 도구 모드 지속적인 통합 및 배달을 사용하기 때문에 제출하지 않은 코드가 업데이트 된 테스트 서버 코드가 완전하고 최신 상태로 보장하므로하지 않는 운영 및 유지 보수 업데이트가 공식 서비스를 직접 테스트 서버 코드를 사용할 수없는 경우, 따라서, 후속 절차를 완료 할 수 없습니다 기존 사용자 지정 업데이트 도구 배포를 계속했다.

젠킨스

젠킨스 도입

젠킨스는 오픈 소스 빌드, 테스트 및 소프트웨어를 배포 포함한 다양한 작업을 자동화하는 데 사용 CI 및 CD (연속 빌드 및 배포) 소프트웨어입니다. 당신은 그래서 파이썬 애플리케이션을 구축 할 pyInstaller 중에와 애플리케이션을 구축 할 Node.js를하고 NPM 자바 애플리케이션을 구축 할 메이븐 반응 사용할 수 있습니다. 젠킨스는 또한 설치 매우 간단하고, 사용하는 공식 웹 사이트 설치 다양한 방법으로 다른 플랫폼 세부 정보, I는 서버가 JDK 환경을 제공하기 때문에 가장 편리한이 실행 전쟁 패키지를 사용하기로 결정했습니다.

사용 젠킨스

jenkins的使用非常简单，只要按照提示一步步进行即可。这里选择最常用的“构建一个自由风格的软件项目”，如果后续步骤比较复杂，可以考虑使用流水线。

现有的构建方式 or Maven改造？

这一步比较关键，Jenkins让我们选择使用何种方式来构建项目。这里我进行了一番斟酌，按照目前苍龙传统的构建方式，是使用javac来编译，然后使用zip来打包应该选择shell方式。但目前这种方式没有持续集成流程中“自动测试”这样一环，而自动测试对于持续集成来讲又非常重要。因此为了加入自动测试以及今后能更方便的构建苍龙服务器代码，最后决定，首先进行Maven的集成。

Maven集成

Maven介绍

Maven是一款专门对Java应用进行依赖管理的工具，它采用了统一的标准（Pom文件）来构建Java应用，使得Java开发者对于项目中使用的依赖组件能够一目了然，很便捷地处理依赖冲突的问题，也能很高效地完成编译、打包等操作。除此之外，Maven还能在打包之前完成自动化单元测试，非常有利于开发人员的自我测试，在功能开发阶段就找出并解决一些Bug。但非常不幸的是，苍龙服务器代码因为一些历史原因，并没有使用Maven。没有条件就创造条件，下面就开始了Maven集成工作。

Maven集成步骤

整理各服务器项目代码（游戏服、战斗服、世界服、日志服）所使用的jar包，区分出公有jar包与私有jar包。
将公有jar包配置为直接从阿里云中央仓库下载，私有jar包上传到私有仓库，再从私有仓库下载。
整理与解决依赖冲突问题

遇到的问题与解决

大部分私有jar包来源未知，并且没有源码，也在开源平台中无法找到（应该是祖传jar包），无法通过编译源码方式deploy到私有仓库。解决方法：在Nexus Repository Manager后台登陆后直接上传jar包。
某些jar包根据名字和内容判断，应该是公有jar包，但是却没有标注版本号（坑啊！），因此无法从阿里云中央仓库中下载。解决方法：作为私有jar包处理。
原项目中jar包冲突却一直没被发现，例如activemq-all-5.10.2.jar与log4j-slf4j-impl-2.1.jar冲突，启动时会提示slf4j重复绑定。解决方法：将all包拆分为单个组件，并使用exclusion标签排除冲突的jar。
原项目代码采用JDK1.6编译，但JDK1.6无法兼容最新版的Maven3.6.x。解决方法：使用最后能支持JDK1.6的Maven3.2.5版本。
（最棘手）项目路径问题。普通Java项目源码路径为ROOT/src，但maven项目的源码路径为ROOT/src/main/java。如果要更改源码路径，那么以前在SVN上建立的分支将无法识别新的源码路径（已经过测试验证）。这个问题引起了我的好奇，并且发现在Git上修改源项目码路径不会有该问题，但是在SVN上就会出现。经过一番比较深入的研究后发现，在Git中如果将某个文件A移动了路径B，git会记录该版本进行了rename A->B，在其他分支上对A的修改仍然可以合并到B。而SVN则不一样，如果文件A移动到了路径B，SVN会记录该版本将A删除，新建了B，在其他分支上对A的修改就无法合并到B。因此，受苍龙使用SVN的限制，就无法修改源码路径，那么如何使Maven能够识别原有的源码路径ROOT/src呢？好在Maven提供了对源码和资源指定的支持：

<sourceDirectory>src</sourceDirectory>
<testSourceDirectory>test/java</testSourceDirectory>
<resources>
    <resource>
        <directory>resources</directory>
    </resource>
</resources>
<testResources>
    <testResource>
        <directory>test/resources</directory>
    </testResource>
</testResources>

至此，Maven集成完毕。

测试集成

Maven已经有了，那么可以开始使用Jenkins进行持续集成了吗？不！不要忘了Maven还有一项重要使命：自动完成单元测试。苍龙服务器代码中虽然之前有引入JUnit包，但是需要手动运行，非常不方便（以前也从来没有手动运行过）。测试集成也比较简单，主要分为两类：

单元测试

静态公共方法(public static ...)：直接在测试类中调用即可。

私有方法(private ...)：这类方法无法在测试类中直接调用，这时候Java的反射调用就能排上用场了：

Method method = xxx.getClass().getDeclaredMethod("xxx", xxx.class,xxx.class);
method.setAccessible(true);
method.invoke(xxx, xxx, xxx);

Spring注入对象的成员方法（service等）：从Spring上下文中获取对象再调用即可。

Mock测试

有时候编写测试代码时会出现这些情况，某个类可能过于复杂，可能因为依赖过多，甚至可能构造方法因为业务需要被设置成了私有（private）访问，导致我们无法直接new出这个对象，这时候怎么测试呢？这时候Mock测试就派上用场了。我选用的是目前使用最广泛的mockito库，步骤如下：

模拟出该对象：XXX mock = mock(XXX.class);
设置XXX.class的xx()方法返回值：when(mock.xx()).thenReturn(xx);

这样就可以在测试代码中，很方便的调用mock.xx()了，非常简单。

以后在每次Maven打包时，就会自动查找test路径下所有类中以@Test注解的所有public void xxx测试方法，如果测试结果与预期不符，就会终止打包，我们便可以在打包阶段就解决掉一些Bug，降低产品的风险。

流程图

类似于之前采用工具的持续集成方式，jenkins的集成流程也分为了程序版与策划版。

程序版流程图

策划版流程图

优化

可以看到，两条流水线的区别就是持续集成不同，程序是检出的代码，并且需要编译、测试、打包；而策划检出的是配置表。

两条流水线采用的是独立运行的方式，程序负责代码的持续集成，策划负责配置表的持续集成。使用了一段时间之后，我们发现，这种方式在开发版本（主线分支）没有问题，因为开发版本只有测试服没有正式服。而到了生产版本（线上分支），如果按照这种方式，程序、策划流水线独立运行，会导致在正式服维护期间，需要重启2次正式服。而正式服的重启又比较重度（需要备份线上数据），这就导致服务器更新时间翻倍（10分钟增加到20分钟）。为了解决上述问题，我对上述方案进行了改进，将两条流水线合并。

流程图如下：

在该优化版本中，将之前的两条流水线相同的部分合并，不同的部分保留（SVN检出配置表、代码）。配置表和代码的产物生成之后，将两份产物合并作为新的产物，再生成版本号，用该版本产物来更新测试服与正式服。

服务器更新操作流程对比

原有更新流程（每一步均为手动操作）：

업데이트 프로세스 (하나의 단계) 기존 :

비교 정보

예는 다음은 / 아니오 지속적인 통합, 배달, 배포의 결과와 비교 :

공식 서비스 유지 보수 시간
- 15 분 15분 + 개발자 운영 및 유지 보수 담당자 : 없음.
- 그들은 : 개발자 일초 (운영 및 유지 보수 인력에 참여할 필요가 없습니다).
공식 서비스 유지 보수 서버 업데이트
- 아니오 : 약 30 분.
- 그들은 : 약 10 분 거리에 있습니다.
운영 복잡성
- 번호 : 매우 복잡한 20 단계.
- 이 : 그냥 마우스를, 그것은 매우 간단합니다.
오류의 확률
- 없음 : 여러 번 코드가 컴파일되지 않기 때문에, 최신 구성 테이블, 기능 업데이트 서비스 및 기타 문제 누락 운영 및 유지 보수 인력을 나타납니다 사용할 계획되지 않은 발생에 오류가, 그것은 (오류를 업데이트 할 경우 높은 20 단계를 수동으로 수행되지 ).
- 그들은 : 거의 제로 스크립트를 업데이트하기위한 테스트 및 검증 절차를 사용하여.

개요

지속적인 통합 및 배포 (CI / CD)를 크게, 개발 효율성을 향상 제품의 품질을 향상, 더욱 제품을 만들 수 있습니다, 프로젝트 초기에 수립되어야한다.
지속적인 배포시 사용자 정의 스타일의 지속적인 통합 도구는 권장 또는 젠킨스 지속적인 통합, 배달 및 배포의 사용을 달성하기 위해 더 어려울 것입니다.
연습 업데이트하거나 공식 서비스 코드 구성 테이블의 시험에 대해 걱정하지 않습니다 이런 식으로하기 때문에 사용자 지정 도구, 코드 또는 구성 테이블의 테스트에 유용 할 수 있음을 입증했다.
오늘은, 개발 운영 팀의 아이디어는 세계에서 인기가있다, 그것은 소프트웨어 개발 (데브) 문화 통신과 운영 및 유지 보수 기술 협력 (OPS)와 "소프트웨어 전송"과 "스키마 변경,"자동화를 통해 과정에 대한 강조는, 건물을 만든다 테스트는 소프트웨어가보다 효율적 빈번하고 신뢰할 수 있습니다 놓습니다.

参考资料: 지속적인 납품 및 개발 운영에 제품 관리자 가이드

세 블랙 드래곤 지속적인 통합 서버, 배달, 배포 도로

머리말