java持续集成开发_适用于Java开发人员的微服务（持续集成和持续交付） java持续集成开发_适用于Java开

java持续集成开发
1.简介如果我们回顾与微服务体系结构相关的挑战，确保每个微服务都能够与每个对等方说正确的语言可能是最困难的挑战之一。我们最近谈论了很多关于测试的话题，但是总是有机会潜入错误。也许是合同的最后时刻发生了变化？还是安全要求得到了加强？以及无意间推动不正确的配置该怎么办？
为了解决这些问题，我们将就持续集成和持续交付的实践进行讨论。那么，这些实践是什么？它们有什么帮助？它们之间有什么区别？
目录

1.简介
2.詹金斯
3. SonarQube
4.淡褐色
5. Buildbot
6.大堂CI
7. Gitlab
8. GoCD
9. CircleCI
10. TravisCI
11. CodeShip
12.大三角帆
13.云
14.云原生
15.结论
16.接下来是什么

持续集成范例提倡将更改尽可能频繁地推送到主流源存储库，同时还要运行完整的构建并执行自动化测试和检查套件。此处的目标是使构建始终滚动并进行测试，从而避免了每个人都在最后一刻尝试合并更改并将项目拖到集成地狱的情况。
持续交付实践通过引入发布流程自动化并确保随时准备发布项目，将持续集成提升到了新的水平。令人惊讶的是，没有多少组织了解持续交付的重要性，但是这种实践是遵循微服务架构原理的绝对必要前提。
公平地讲，持续交付并不是终点。持续部署过程通过将自动化发行版部署的支持直接引入实时系统来结束循环。持续部署的存在表明成熟的开发组织。
2.詹金斯对于许多人来说，持续集成一词立即引起詹金斯的注意。实际上，它可能是部署最广泛的持续集成（和持续交付）平台之一，尤其是在JVM生态系统中。

Jenkins是一个自包含的开源自动化服务器，可用于自动化与构建，测试以及交付或部署软件有关的各种任务。 – https://jenkins.io/doc/

詹金斯（Jenkins）有一个有趣的故事，它本质上催生了两个截然不同的阵营：一个讨厌它的人，另一个喜欢它的人。幸运的是，几年前发布的詹金斯 2.0版确实改变了游戏规则，席卷了创新海啸。
为了说明Jenkins的功能，让我们看一下JCG Car Rentals平台如何使用管道来连续构建和测试其微服务项目。

文章图片
Jenkins的JCG租车微服务
Jenkins的真正瑰宝在于它的可扩展性和大量可用的社区插件。您可能还记得，所有JCG租车项目都与SpotBugs集成在一起，以进行静态代码分析和OWASP依赖项检查，以捕获易受攻击的依赖项。毫不奇怪， Jenkins拥有这两种插件，就像一个客户服务部一样，它们很容易注入到构建管道中。

pipeline { agent anyoptions { disableConcurrentBuilds() buildDiscarder(logRotator(numToKeepStr:'5')) }triggers { pollSCM('H/15 * * * *') }tools { jdk "jdk-8u202" }stages { stage('Cleanup before build') { steps { cleanWs() } }stage('Checkout from SCM') { steps { checkout scm } }stage('Build') { steps { withMaven(maven: 'mvn-3.6.0') { sh "mvn clean package" } } }stage('Spotbugs Check') { steps { withMaven(maven: 'mvn-3.6.0') { sh "mvn spotbugs:spotbugs" } script { def spotbugs = scanForIssues tool: [$class: 'SpotBugs'], pattern: '**/target/spotbugsXml.xml' publishIssues issues:[spotbugs] } } }stage('OWASP Dependency Check') { steps { dependencyCheckAnalyzer datadir: '', hintsFile: '', includeCsvReports: false, includeHtmlReports: true, includeJsonReports: false, includeVulnReports: false, isAutoupdateDisabled: false, outdir: '', scanpath: '', skipOnScmChange: false, skipOnUpstreamChange: false, suppressionFile: '', zipExtensions: '' dependencyCheckPublisher canComputeNew: false, defaultEncoding: '', healthy: '', pattern: '', unHealthy: '' } } }post { always { archiveArtifacts artifacts: 'target/*.jar', fingerprint: true archiveArtifacts artifacts: '**/dependency-check-report.xml', onlyIfSuccessful: true archiveArtifacts artifacts: '**/spotbugsXml.xml', onlyIfSuccessful: true } } }

一旦在Jenkins上触发了管道作业， SpotBugs和OWASP依赖项检查报告将作为构建结果的一部分发布。

文章图片
SpotBugs和OWASP依赖项检查保持纪律并遵守持续整合的原则至关重要。构建应保持健康并一直通过。
关于Jenkins ，有很多事情要说，特别是关于它与Docker的集成，但是让我们更好地了解其他选择。
3. SonarQube 我们已经在本教程的前面部分讨论过SonarQube 。公平地讲，它不适合连续集成或连续交付，而可以形成互补，即连续代码质量检查。

SonarQube 是一个开源的平台，以执行与代码的静态分析，自动审查，以检测在25+的编程语言如Java，C＃，JavaScript中，打字稿，C / C ++，COBOL和错误，代码味道和安全漏洞更多。 …– https://www.sonarqube.org/about/

SonarQube代码合格检查的结果具有巨大价值。为了一窥它们，让我们看一看客户服务代码质量仪表板。

文章图片
客户服务代码质量检查如您所见， SpotBugs和OWASPdependency -check生成的报告有些交叉，但是SonarQube检查的范围更广。但是，使SonarQube成为持续集成管道的一部分有多么困难？由于SonarQube与Apache Maven ， Gradle甚至Jenkins进行了出色的集成，因此它尽可能地容易实现。
SonarQube支持25种以上的编程语言，无疑会帮助您提高整个微服务团队的代码质量和可维护性（即使您选择的持续集成平台不具备现成的集成功能）。
4.淡褐色 Bazel来自Google ，是内部用于构建公司服务器软件的一种工具。它并非指定为持续集成的主干，而是其背后的构建工具。

Bazel 是类似于 Make ， Maven 和 Gradle 的开源构建和测试工具 。 它使用人类可读的高级构建语言。 Bazel支持多种语言的项目，并为多种平台构建输出。 Bazel 支持跨多个存储库的大型代码库以及大量用户。 – https://docs.bazel.build/versions/master/bazel-overview.html

Bazel有趣的是，它专注于更快的构建（高级的本地和分布式缓存，优化的依赖关系分析和并行执行），可伸缩性（在许多存储库或庞大的Monorepo中处理任何大小的代码库）以及对多种语言（Java）的支持包括在内。在多语言微服务领域，具有相同的构建工具经验可能会非常有利。
5. Buildbot 本质上， Buildbot是一个作业调度系统，它支持跨多个平台的作业的分布式并行执行，与不同源控制系统的灵活集成以及广泛的作业状态报告。

Buildbot 是用于自动化软件构建，测试和发布过程的开源框架。 – https://buildbot.net/

Buildbot非常适合满足混合语言应用程序（例如polyglot 微服务）的需求。它是用Python编写的，并且在很大程度上依赖于Python脚本来执行配置任务。
6.大堂CI Concourse对自动化采用了通用的方法，使其特别适合支持持续集成和持续交付。

广场是一个开放源代码的连续事物。 – https://concourse-ci.org/

Concourse中的所有内容都在容器中运行，非常容易上手，其核心设计原则鼓励使用声明性管道（坦白地说，它与Jenkins或GoCD的管道完全不同）。例如，客户服务的基本管道可能如下所示：

resources: - name: customer-service type: git source: uri: branch: master jobs: - name: build plan: - get: customer-service trigger: true - task: compile config: platform: linux image_resource: type: docker-image source: repository: maven inputs: - name: customer-service outputs: - name: build caches: - path: customer-service/.m2 run: path: sh args: - -c - mvn -f customer-service/pom.xml package -Dmaven.repo.local=customer-service/.m2

此外， Concourse带有命令行工具和非常基本的Web UI，尽管如此，它有助于可视化您的管道，如下图所示。

文章图片
Web用户界面中的会议管道 7. Gitlab Gitlab是一个成熟的开源端到端软件开发平台，具有内置的版本控制，问题跟踪，代码审查，持续集成和持续交付。

GitLab 是整个软件开发生命周期中的单个应用程序。 从项目计划和源代码管理到CI / CD，监视和安全。 – https://about.gitlab.com/

如果您正在寻找可以自托管或在云中管理的多合一解决方案，那么肯定可以考虑选择Gitlab 。让我们看一下在选择了Gitlab的情况下客户服务项目的开发情况。

文章图片
Gitlab中的客户服务持续集成和持续交付管道相当可扩展，默认情况下至少包括三个阶段：构建，测试和代码质量。

文章图片
Gitlab中的客户服务CI / CD管道值得注意的是，许多公司都在使用Gitlab ，并且它的普及和采用正在稳步增长。
8. GoCD 我们要讨论的下一个主题GoCD来自ThoughtWorks ，该组织以在大多数软件开发领域雇用世界级专家而闻名。

GoCD 是 ThoughtWorks的 开源构建和发布工具 。 GoCD 支持现代基础架构，并帮助企业业务更快，更安全，更可靠地交付软件。 – https://www.gocd.org/

毫不奇怪，管道也是GoCD中的核心部分。它们充当工作流或工作流一部分的表示。 GoCD附带的Web UI非常直观，简单易用。下图中的客户服务管道就是一个很好的例子。

文章图片
JCG租车管道管道本身可以包含任意数量的阶段，例如，客户服务的阶段有两个阶段，即“ 构建”和“ 测试” 。专用视图详细展示了每个阶段的执行情况。

文章图片
客户服务管道 GoCD管道非常通用，不会偏向任何编程语言或开发平台，因此可以满足多种语言微服务项目的需求。
9. CircleCI 如果自托管（或者换句话说，内部部署）解决方案与您的计划不一致，那么周围会有很多SaaS产品。 CircleCI是最受欢迎的选择之一。

CircleCI 的持续集成和交付平台使各种规模的团队都可以轻松快速地大规模构建和发布高质量的软件。 在云中或防火墙后为Linux，macOS和Android构建。 – https://circleci.com/

除了是一个伟大的产品，的原因之一CircleCI被列入我们的名单是存在自由层，让你快速上手。
10. TravisCI TravisCI与CircleCI属于SaaS产品类别，但有一个重要区别–它对开源项目始终免费。

Travis CI 是托管的持续集成和部署系统。 – https://github.com/travis-ci/travis-ci

TravisCI可能是最受欢迎的持续集成服务，用于构建和测试GitHub上托管的软件项目。从不太光明的一面来看， TravisCI的未来尚不清楚，因为它是在2019年1月被私募股权公司收购的，并且据说最初的开发团队被放开了。
11. CodeShip CodeShip是另一个用于进行持续集成和持续交付的 SaaS ，最近被CloudBees收购，它也提供免费计划。

Codeship 是一种快速安全的托管持续集成服务，可根据您的需求进行扩展。 它支持 GitHub ， Bitbucket 和 Gitlab 项目。 – https://cms.codeship.com/

CodeShip的显着优势之一是，几乎不需要（或很少）时间就可以对其进行设置和运行。
12.大三角帆到目前为止，我们讨论的大多数选项都试图涵盖同一框架下的持续集成和持续交付。另一方面，最初由Netflix创建的Spinnaker则纯粹专注于事物的连续交付方面。

Spinnaker 是一个开源的，多云的连续交付平台，用于以高速度和信心发布软件更改。 – https://www.spinnaker.io/

它是真正独一无二的解决方案，将灵活的连续交付管道管理与与领先的云提供商的集成相结合。
13.云托管自己的持续集成和持续交付基础结构可能远远超出了人们的能力范围。我们已经讨论过的SaaS产品可以显着加快入门速度并降低前期成本，至少在您刚开始的时候。但是，如果您在云中（这几天可能会更多），那么从云提供商为您提供的服务中受益是很有意义的。让我们看看云计算的领导者们提出了什么。
我们列表中的第一个肯定是AWS ，它有两个与持续集成和持续交付有关的产品，分别是AWS CodeBuild和AWS CodePipeline 。

AWS CodeBuild 是一项完全托管的 持续集成 服务，可编译源代码，运行测试并生成准备部署的软件包。 使用 CodeBuild ，您无需配置，管理和扩展自己的构建服务器。 …– https://aws.amazon.com/codebuild/

AWS CodePipeline 是一项完全托管的 持续交付 服务，可帮助您自动化发布管道，以实现快速，可靠的应用程序和基础架构更新。 每当 您更改代码时， CodePipeline 都会根据您定义的发布模型自动执行发布过程的构建，测试和部署阶段。 …– https://aws.amazon.com/codepipeline/

转到Google Cloud ，我们将偶然发现Cloud Build产品，这是Google Cloud持续集成工作的基础。

通过Cloud Build ，您可以跨所有语言快速构建软件。 完全控制定义用于在多个环境中进行构建，测试和部署的自定义工作流程…– https://cloud.google.com/cloud-build/

Microsoft Azure走了另一条路，从托管Jenkins产品开始。但是在GitHub收购之后不久， Azure DevOps出现了，这是一个全新的产品，它通过持续集成，持续交付和持续部署产生。

Azure DevOps Services提供了开发协作工具，其中包括高性能管道，免费的私人 Git 存储库，可配置的 看板 板以及广泛的自动化和连续测试功能。 …。 – https://docs.microsoft.com/zh-CN/azure/devops/index?view=azure-devops

14.云原生在总结之前，最好先看看现有的持续集成和持续交付解决方案如何适应不断变化的基础设施和运营环境。这个领域正在发生许多创新，让我们看看一些有趣的发展。
首先， Jenkins 最近宣布了新的子项目Jenkins X ，专门针对基于Kubernetes的部署。我认为这种趋势将继续下去，并且由于Kubernetes的普及率在飞速上升，其他参与者也将迎头赶上。
无服务器执行模型的传播使持续集成和持续交付成为新的视角。在这方面，值得一提的是LambCI ，这是一个基于AWS Lambda构建的持续集成系统。我们很可能会在这方面看到更多的选择。
15.结论如今，持续集成的重要性不容置疑。从另一方面来说，持续交付和持续部署落后了，但是它们无疑是微服务原理的组成部分。
在本教程的这一部分中，我们浏览了很多选项，但显然还有许多其他选项。但是重点不是特定的解决方案，而是实践本身。由于您踏上了微服务之旅，因此使它顺利进行也是您的责任。
16.接下来是什么在本教程的下一部分中，我们将深入研究与微服务架构相关的操作问题，并讨论配置管理，服务发现和负载平衡。