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