这是我们的议程，我们会介绍我自己，然后我们会介绍我们的发布周期平台，我们会讨论架构，差异化因素和关键特性。然后我们将跳转到发布周期和JFrog集成用例。然后我们会有那些集成用例的演示。然后我们将总结这节课。这是关于我自己的，我在领导跨职能工程团队，开发，QA, DevOps, SRE方面有20多年的经验。我的热情一直是实现过程，以更快地交付高质量的软件。
所以你知道，我在我的职业生涯中花了很多时间研究这个问题。我创办了一家公司，在这个领域开发一种产品。我喜欢旅行，希望我能很快再次开始旅行。这是我们的DevOps平台。我们的服务器位于AWS云上。这是我们的代理，它位于客户的网络上，我们的代理负责与所有客户的工具进行沟通。代理可以安装在私有云和公有云上。代理和服务器之间的通信是单向的。
我们不会在云端保存任何机密信息。所有的机密信息都将存储在代理中。当然，这是一个SaaS应用程序。我相信你们中的一些人在想，另一个CI / CD管道产品?这是一个公平的问题，因为市面上有很多CI / CD产品。hth华体会最新官方网站但是等等，我们的ReleaselQ平台是不同的。为什么?
ReleaselQ不仅仅是一个CI / CD流水线产品。它是一个统一的DevOps平台，为什么我们称它为统一的DevOps平台?想想任何中型或大型企业，他们会有不止一个应用程序，这些应用程序可能是新的云原生到传统的单片本地应用程序，对吧?一些应用程序将在应用程序现代化的旅程中。因此，我们的产品ReleaselQ可以与DevOps团队已经为现有应用程序投资的一些CI / CD工具集成。
此外，ReleaselQ平台还可以用于从头开始为新的云原生应用程序创建CI\CD管道。这就是为什么我们称它为统一的DevOps平台。所以你会觉得有多个应用程序，每个应用程序都有不同的架构，在本地，SaaS，它是一个云原生，微服务，整体。您是否投资了一些CI / CD工具或脚本并不重要。你可以使用ReleaselQ来自动化所有这些产品的发布过程，并有一个统一的[听不清]。hth华体会最新官方网站
这是我们产品的截图，这里你可以看到来自四个不同产品的管道，比如ABC是一个现有的应用产品，这些是全新的基于微服务的应用，ABC你可以看到我们使用Circle CI, 4 CI, Jehth华体会最新官方网站nkins作为CI，它来自两个不同的团队。然后我们有CD使用我们的产品我们将它与这两个管道集成然后我们有CD步骤使用ReleaselQ。
产品B是bamboo和ReleaselQ产品CS Jenkins和Spinnaker产品B，正如我所说，这是一个全新的基于微服务的应用程序，你可以使用ReleaselQ从头开始做CI\CD。这里是统一视图，demo中我们会看到更多。以及持续的测试。所以当你有一个CI管道的时候，几乎所有的测试都是自动化的。当您在CI管道中配置测试时，它将是一个自动化的测试。
但是当涉及到CD时，您将同时拥有自动和手动测试，并且我们有能力让DevOps管理员将自动和手动测试过程嵌入到管道中。所以不仅仅是嵌入，通过这样做所有的利益相关者都可以看到测试结果。如果出现了故障，他们可以查看故障原因，调试，排除故障，他们可以对它做任何他们想做的事情。
持续测试是我们DNA的一部分。我们帮助人们快速解决管道故障。如何?我们收集所有相关的日志，从所有不同的来源，从部署任务，测试任务，测试基础设施，部署基础设施，我们收集所有的日志，然后我们应用一些分析，我们提供根本原因分析，或者我们也提供工作空间，让他们去比较日志，当事情成功时，当它失败时。例如，假设构建成功与失败，他们可以比较两组日志并找出根本原因。
我们还为他们提供了查看所有原始日志的功能，因此他们也可以在自己的墙上进行调试。当我说他们，开发人员，测试人员，任何应该调试特定测试失败的人。所以我们的平台是一个以人为中心的DevOps平台，为什么我们称之为以人为中心?它对你团队中的每个人都有价值。开发人员，他们有从提交到生产的端到端可见性，他们可以查看测试失败，部署失败，构建失败，他们可以排除故障。QA人员，他们实际上可以看到他们运行的所有自动化测试的整合视图，哪个测试套装失败最多哪个测试用例失败最多，他们可以排除故障。
DevOps人员可以看到他们创建的所有管道，在一个地方，他们可以找到瓶颈并排除问题。经理们，我们为他们提供生产力指示板和洞察力，以提高发布效率。这是发布过程中每个利益相关者都要做的事情。下面是我们谈话的摘要。所以我们的平台发布周期平台，它支持现有的DevOps流程和CI / CD工具链，无论你使用哪个应用程序，无论你在DevOps旅程中处于什么位置，无论你使用的是云应用程序，无论你使用的是本地应用程序还是SaaS应用程序，都没关系，你可以使用ReleaselQ平台。我们可以在管道中嵌入自动和手动测试结果，我们看到了先进的故障排除和智能根本原因分析功能，以减少mttr，然后它是一个以人为中心的DevOps平台。
这些都是我们产品的区别和关键特征。说到这里，我想进入JFrog集成用例。所以有了我们的平台，当你带来JFrog的产品，比如artifactory, X rayhth华体会最新官方网站和JFrog pipeline，你就可以真正实现端到端的DevOps平台作为一个服务。通过这样做，这些就是您可以解决的所有用例。第一个用例，持续交付管道的预置应用程序。
从JFrog工件监听并部署到QA环境，运行测试并部署到UAT。这是预付费应用。有些公司甚至是预付费应用，他们有这种持续的交付过程。他们现在有我们的UAP环境，他们不断地向那个环境交付。我就这么做过，持续交付的应用非常有用。通过与JFrog artifactory集成，您可以使用我们的产品创建这些管道。
你将看到的第二个用例是，假设你有一个基于微服务架构的Kubernetes服务需要一直到生产。所以您现在没有在您的环境中使用任何CI / CD工具，它是一个新产品。你可以使用我们的产品，从监听，从GitHub，到部署到生产，特别是一些高级的部署策略，比如罐头，你可以使用我们的产品做所有的事情。我们再次使用Gradle，构建并上传到artifactory, X射线，使用X射线扫描账单，部署到阶段，运行自动和手动测试，获得SRE的批准并部署到生产环境。所以你能做的就是。
第三个用例，假设你有一个应用，它是一个基于微服务的架构，你有两个组件，两个服务，它们都是不同的团队，它们使用不同的工具，一个团队使用Jenkins管道，另一个团队使用JFrog管道。最后，他们监听、构建、做一些单元测试，然后将构建上传到artifactory。然后用X射线扫描。然后您想要使用这些构建，一旦它通过，您想要使用这些构建并一起部署到阶段。
QA团队运行一些手动测试，手动和自动测试，然后通过审批，部署到生产中。因此，在本例中，我们只使用现有的Jenkins作业进行部署。但是在前面的用例中，没有Jenkins，我们使用ReleaselQ产品来编排这个管道。在这种情况下，我们也使用Jim Jenkins和JFrog artifactory。所以有三个用例，通过监听的持续交付管道，JFrog人工制造，使用ReleaselQ从头开始的CI / CD管道，然后是CI管道，外部CI管道聚集在一起并与CD管道连接。
所以你可以有端到端的可视性。这是我们将在演示中看到的三个用例。我们来看乘积。这是swump . releaseq .io。当你登录产品时，这是管理区域，你可以进入设置。顺便说一下，这就是DevOps，对吧?负责为应用程序创建管道的DevOps工程师或DevOps架构师。所以他们来到这里，他们不能弄清楚所有这些，你知道，在你的发布过程中所有的DevOps工具，他们会在这里配置，这里的产品是什么，我已经创建了SwampUP产品，SwampUP团队和一堆组件。所以他们配置SCM, CI，你使用什么环境，你使用什么测试工具，你使用什么bug工具，你使用什么部署工具，你在这里使用什么构建器存储库，我们配置了工件。在这里，我们不仅将工件配置为工具，您还可以从我们的产品中创建web hook，您可以从我们的产品中创建JFrog web books。 You can actually use this web hooks directly in our pipeline when you compose the pipeline.
这就是你配置X光的地方。在今天的演示中，我想让你们知道一些东西。一个是我们从GitHub上监听，我们有不同的配置，我们配置了x射线。在今天的演示中我们没有使用部署工具，bug管理工具。让我来看看管道作曲器。
这是DevOps管理员创建管道的地方，它是一个拖放管道。我今天不打算创建一个管道，我们已经创建了一些管道。我要讲一下。这是第一个用例。听听Artifactory的报道。因此，当您拖放此触发器时，您将选择构建存储库。
这是我们已经做过的人工配置。这是我们已经使用我们的产品创建的web钩子，它在设置部分进行了配置。你基本上选择你想在这个管道中使用哪个web钩子。然后你想如何部署，我想使用我的Jenkins作业来部署，这是一个作业它有一个参数，它是一个文件路径。这个文件路径是从我们从web钩子获得的有效负载传递过来的。所以我们需要倾听。这就是我们创建web hook的原因，我们获得有效载荷，我们获得文件路径，我们将文件路径作为参数传递给下一个部署作业。
然后我们配置自动化测试。再一次，这是一个J单元测试我们有一个叫做质量门的概念，你可以说允许管道继续进行，即使测试失败，你知道如果你说不，它会在失败时停止，如果你说是，并设置一些故障容忍度，在这种情况下，我们设置25%，这意味着低于25%，它会好的，大约25%的管道会停止。你也可以在这里配置手动测试，这就是你要做的。你选择手动，手动输入，什么是格式，这是我们已经配置的格式。再一次，在这种情况下，质量门，即使有一个失败，我们将停止管道。然后是批准步骤，然后部署到UAT。
就像我们部署到QA时一样。使用Jenkins作业，我们将其配置为您创建的第一个管道。然后你启用它。当您启用此功能时，开发人员将开始看到端到端。我们一会儿就会看到。第二个管道是Kubernetes服务。这里我们从ACM内部构建存储库中侦听，从ACM中侦听，并使用Gradle进行构建。
在这里你可以看到我们正在构建，我们正在将其上传到JFrog存储库。我们正在用JFrog X射线扫描。所以你可以做所有这些事情，然后我们听Artifactory。然后我们把它部署到舞台上。在这种情况下，我们不使用Jenkins，我们使用内部部署工具进行部署，我们使用滚动更新作为策略。然后我们运行自动化测试。然后有一个批准步骤，然后我们将其部署到生产中。在这种情况下，我们使用罐头厂，当我们选择罐头厂时，你也可以做罐头厂验证。
有三种方法可以验证你的Canary部署:使用我们自己的见解，使用一些测试，使用外部见解，你可以从一些可观察性工具(如app dynamics和New Relic)中获得见解。你可以在罐头厂验证之后进行手动步骤在你推出之前或者你可以使用自动推出。在本例中，我们正在进行自动推出。这是第二个管道，从CEM一直到生产，Canary部署。
第三条管道由两个部分组成。一个是使用Jenkins管道，你可以看到这是你导入Jenkins的方式。所以去选择你的Jenkins并选择管道，然后你会自动看到所有的步骤。然后你会听到Jenkins管道接近的人工制品然后它连接到释放管道。第二个管道，组件CI管道在这里使用JFrog管道。同样的方法，你选择JFrog工具，然后选择你想要导入的管道，你直接导入，然后你从Artifactory和管道连接器被用来连接到发布管道。
发布管道是一堆部署到阶段、运行功能测试、手动测试、批准流程、部署到生产环境的步骤。几分钟后，你就可以在设置部分进行配置，你可以配置所有的DevOps工具，然后在这里创建管道。我们的目标是不到30分钟，我们希望我们的DevOps管理员，你们的DevOps管理员为你们现有的应用和新的应用创建管道。这就是我们的目标，这就是你们在这里看到的。一旦DevOps管理员创建了这个管道，然后启用它，这是开发人员看到的视图，让我转到样本2产品。这是提交视图。这是第一个管道，从Artifactory一直听到UAT环境。
该管道目前正在等待某人上传手动测试结果。你怎么上传?你点击这里，就可以提取。我要在这里上传。我将搜索样本和测试通过，然后我的提取，我说我的测试周期已经完成，所以我保存它。现在它正在上传手工测试结果。让我们来看看一些已经完成的管道。这就是完成的管道的样子。正如您所看到的，自动化测试失败了，尽管失败了，我们仍然继续。原因是质量门。
你知道，假设开发人员在看这个，他们看一个测试用例失败，然后他们可以点击，他们可以看到我们显示的根本原因，或者他们可以自己去解决问题。这是失败，他们可以把这个和另一个成功的运行进行比较，他们可以比较两次运行，我们按时间顺序展示，这样他们更容易排除故障。或者他们可以查看所有的日志所有相关的日志。他们自己可以检查和调试问题。
这是第一条管道。现在让我们转到第二个管道，那是微服务管道，在这个例子中，我们从GitHub监听，我们使用Gradle构建，将其上传到Artifactory，使用X射线扫描，从Artifactory监听，将其部署到舞台。现在这个管道失败了，为什么?自动化测试失败了，因为当测试失败时，我们说的质量检验关不向前推进。这就是它失败的原因。现在我们来看看其他几个例子。在这条管道中，它一路到达生产阶段。所以你可以看到这是我们做罐头工厂部署时的样子。现在这个部署成功了。在这种情况下，它失败了。 This is how it looks like, the canary verification failed.
当金丝雀验证失败时，推出不会执行，人们可以点击这里的按钮查看金丝雀验证失败的所有日志。这是第二条管道。第三个管道是两个组件结合在一起，我们看到第一个组件使用Jenkins管道。这是管道的完整的端到端视图。然后是组件二，它使用JFrog管道。
这是另一个你知道，这是管道的端到端视图。因此，在这种情况下，自动测试和手动测试都失败了，并且因为手动测试失败而无法继续进行。所以你所看到的是，当DevOps管理员创建这些管道时，开发人员可以看到从提交到生产的执行视图。不仅是端到端可见性，他们可以看到故障，也可以排除故障。还有一些其他的仪表盘，我们称之为QA仪表盘。
我们允许人们，测试人员来这里看看他们在管道中运行了多少个测试套件，什么时候测试通过了，什么时候失败了，有多少测试通过了，有多少测试失败了，他们可以看到所有这些。我们有两个仪表盘。我们也有我们的DevOps工程师，他们可以看到他们在他们的环境中运行的所有管道，在线设备、软件即服务、应用程序、管道，任何种类的管道，我们在这里展示的所有管道，过去七天有多少，有多少通过了，有多少失败了，哪里通过了，哪里失败了，瓶颈在哪里……他们可以看到所有这些东西。然后我们有一个执行摘要，这是给经理的。
所以我们有一些DevOps指标，什么是部署频率，什么是部署前置时间，他们可以按产品，按团队，按组件来看，部署前置时间也是一样。我们也提供见解。因为我们有所有的管道数据，我们运行分析，我们给他们一些可操作的见解。
例如，在这种情况下，一些审批需要超过24小时。现在，经理或任何负责审核的人，他们可以和审批人谈谈，看看他们为什么要花更多的时间来审核，对吧?同样的，这个特定的测试套件失败了。现在他们有了测试套件失败的上下文。现在他们可以用上下文联系测试人员，他们可以进行更高效的沟通，也可以进行在那个时间框架内发生的一些提交。
你也可以根据产品来过滤，你可以用任何方式来过滤产品，团队，组件，这些都可以在这里做。这里的另一个视图，管道摘要。这是我在幻灯片中展示的截图。
这是跨产品团队组件的所有产品管道的整合视图或统一视图，无论你在公司中有什么管道，你都能看到所有这些，有多少提交通过了管道hth华体会最新官方网站，有多少提交到达了产品或目的地，如果是在prem app上，哪里有瓶颈，在我们的例子中，我们使用SwampUP 2产品所以我过滤掉了SwampUP 2产品。
这些是所有的管道。正如你所看到的，这是一个onprem，这是一个微服务管道，这是两个管道，JFrog和Jenkins管道结合在一起并交付到生产环境中。所以你可以看到所有的管道都在一个地方。不仅如此，如果有问题，你可以点击查看，在这种情况下，我知道它运行了14次，4次失败了，你可以确切地看到它为什么失败了，在什么时候失败了。现在，无论谁在看它，他们都可以和负责这个部署的人进行更好的讨论，对吧?大多数情况下是DevOps人员，经理可以与该人员进行更好的讨论。这就是我们的乘积。
现在，我将再次跳到幻灯片上。让我总结一下。所以我们看到了我们统一的DevOps平台，差异化和关键功能，它如何支持云原生和传统应用，在本地，SaaS应用。它没有核心的拖放管道。
它具有基于提交的端到端可见性，连续测试DNA部分，并具有高级故障排除功能以降低mttr。它具有基于角色的指示板和生产力洞察力，以提高发布效率。我们还讨论了如何集成JFrog产品，我们看到了如何通过与artifactory集成来创建一个持续的交付管道。hth华体会最新官方网站
我们看到了如何通过集成artifactory和X射线为Kubernetes微服务做CI\CD管道。我们还看到了如何与Jenkins管道和JFrog CI管道集成，以及如何创建CD管道。我们也为参加SwampUP的人提供优惠。
所以我们提供6个月免费的高级版本。因此，您应该能够使用您的与会者电子邮件id并获得此优惠，一旦您注册，我们可以发送有关它的更多详细信息。我们希望您使用这个报价，并尝试使用我们的产品，并给我们反馈。
非常感谢。再见。
