Merge pull request #408 from wenchaoh997/zh_cn
This commit is contained in:
Michael Cade
GitHub
commit
f46eb66637
@ -1,115 +1,116 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - The Big Picture: CI/CD Pipelines - Day 70'
|
||||
title: '#90DaysOfDevOps - 概览：CI/CD 管道 - 第七十天'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The Big Picture CI/CD Pipelines
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
description: 90DaysOfDevOps - 概览：CI/CD 管道
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048836
|
||||
---
|
||||
## The Big Picture: CI/CD Pipelines
|
||||
|
||||
A CI/CD (Continous Integration/Continous Deployment) Pipeline implementation is the backbone of the modern DevOps environment.
|
||||
## 概览：CI/CD 管道
|
||||
|
||||
It bridges the gap between development and operations by automating the build, test and deployment of applications.
|
||||
CI/CD（持续集成/持续部署）管道实现的是现代DevOps环境的支柱。
|
||||
|
||||
We covered a lot of this Continous mantra in the opening section of the challenge. But to reiterate:
|
||||
它通过自动化应用程序的构建、测试和部署，将开发和运营联系了起来。
|
||||
|
||||
Continous Integration (CI) is a more modern software development practice in which incremental code changes are made more frequently and reliabily. Automated build and test workflow steps triggered by Contininous Integration ensures that code changes being merged into the repository are reliable.
|
||||
我们在挑战的开头部分介绍了很多这种持续不断的“咒语”。但这里要重申：
|
||||
|
||||
That code / Application is then delivered quickly and seamlessly as part of the Continuous Deployment process.
|
||||
持续集成（CI）是一种更现代的软件开发实践活动，其想法是使代码增加、更改得更频繁、更可靠。由持续集成触发的自动化构建和测试工作流步骤确保了合并到仓库中的代码变更是可靠的。
|
||||
|
||||
### The importance of CI/CD?
|
||||
作为持续部署过程的一部分，这些代码/应用程序将快速无缝地交付。
|
||||
|
||||
- Ship software quickly and efficiently
|
||||
- Facilitates an effective process for getting applications to market as fast as possible
|
||||
- A continous flow of bug fixes and new features without waiting months or years for version releases.
|
||||
### CI/CD的重要特点？
|
||||
|
||||
The ability for developers to make small impactful changes regular means we get faster fixes and more features quicker.
|
||||
- 快速高效地推送软件
|
||||
- 是帮助应用程序尽快推向市场的有效流程
|
||||
- 持续不断地进行错误修复和新功能添加，且无需等待数月或数年进行版本发布。
|
||||
|
||||
### Ok, so what does this mean?
|
||||
开发人员能够定期进行有影响力的小变更，这意味着我们可以更快地进行修复和添加更多功能。
|
||||
|
||||
On [Day 5](day5.md) we covered a lot of the theory behind DevOps and as already mentioned here already that the CI/CD Pipeline is the backbone of the modern DevOps environment.
|
||||
### 所以这意味着什么？
|
||||
|
||||
|
||||
在[第五天](day05.md)，我们介绍了DevOps背后的许多理论。正如这里已经提到的，CI/CD管道是现代DevOps环境的支柱。
|
||||
|
||||
I want to reiterate some of the key points on this image above, now that we are a little further into our journey of learning the fundamentals of DevOps.
|
||||
|
||||
|
||||
We are referring to the software development life cycle (SDLC).
|
||||
我想重申上图中的一些关键点，现在我们在学习DevOps基础知识的过程中又向前迈进了一步。
|
||||
|
||||
The steps are usually written out within an infinity loop since it's a cycle that repeats forever.
|
||||
我们指的是软件开发生命周期（SDLC）。
|
||||
|
||||
The steps in the cycle are, developers write the **code** then it gets **built** or all compiled together then it's **tested** for bugs then it's **deployed** into production where it's used (**Operated**) by end users or customers then we **monitor** and collect feedback and finally we **plan** improvements around that feedback **rinse and repeat**.
|
||||
这些步骤通常是在无限循环中的，因为这是一个一直重复的循环流程。
|
||||
|
||||
### Let's go a little deeper into CI/CD
|
||||
这个循环中的步骤是，开发人员编写**代码code**，然后将其**构建built**或全部编译在一起，对其中的bugs进行**测试tested**，接着是**部署deployed**到最终用户或客户（**操作/使用operated**）的产品中，然后我们**监控monitor**并收集反馈，最后我们围绕收集到的反馈进行**计划plan**并**重复rinse and repeat**。
|
||||
|
||||
### CI
|
||||
### 更深入了解 CI/CD
|
||||
|
||||
CI is a development practice that requires developers to integrate code into a shared repository several times a day.
|
||||
### CI 持续集成
|
||||
|
||||
When the code is written and pushed to a repository like github or gitlab that's where the magic begins.
|
||||
CI是一种开发实践活动，要求开发人员每天多次将代码集成到共享的仓库中。
|
||||
|
||||
|
||||
当代码被编写并推送(pushed)到Github或GitLab这样的仓库时，魔法就开始了。
|
||||
|
||||
The code is verified by an automated build which allows teams or the project owner to detect any problems early.
|
||||
|
||||
|
||||
|
||||
代码通过一个自动化构建活动进行验证，这个步骤可以使团队或项目所有者尽早发现问题。
|
||||
|
||||
From there the code is analysed and given a series of automated tests three examples are
|
||||
|
||||
|
||||
- Unit testing this tests the individual units of the source code
|
||||
- Validation testing this makes sure that the software satisfies or fits the intended use
|
||||
- Format testing this checks for syntax and other formatting errors
|
||||
提交的代码会被分析，并给出了一系列自动化测试，这里给出三个例子
|
||||
|
||||
These tests are created as a workflow and then are run every time you push to the master branch so pretty much every major development team has some sort of CI/CD workflow and remember on a development team the new code could be coming in from teams all over the world at different times of the day from developers working on all sorts of different projects it's more efficient to build an automated workflow of tests that make sure that everyone is on the same page before the code is accepted. It would take much longer for a human to do this each time.
|
||||
- 单元测试，测试源代码的各个单元
|
||||
- 验证测试，确保软件满足或适合预期用途
|
||||
- 格式测试，检查语法和其他格式错误
|
||||
|
||||
|
||||
这些测试是作为一个工作流被创建，每当你推送到主分支(master branch)时都会运行。所以几乎每个主要的开发团队都有某种CI/CD工作流。请记住，在开发团队中，新代码可能会在一天中的不同时间从世界各地的团队、从事各种不同项目的开发人员那里传入到测试的工作流程中。因此确保在接受代码之前每个人都在同一页面上。人们每次都要花更长的时间才能做到这一点。
|
||||
|
||||
Once we have our tests complete and they are successful then we can compile and send to our repository. For example I am using Docker Hub but this could be anywhere that then gets leveraged for the CD aspect of the pipeline.
|
||||
|
||||
|
||||
|
||||
一旦我们完成了测试并通过，我们就可以编译它们并将其发送到我们的仓库。例如，我正在使用Docker Hub，但这可能是任何可以用于管道的CD（持续部署）的地方。
|
||||
|
||||
So this process is obviously very much down to the software development process, we are creating our application, adding, fixing bugs etc and then updating our source control and versioning that whilst also testing.
|
||||
|
||||
|
||||
Moving onto the next phase is the CD element which in fact more and more is what we generally see from any off the shelf software, I would argue that we will see a trend that if we get our software from a vendor such as Oracle or Microsoft we will consume that from a Docker Hub type repository and then we would use our CD pipelines to deploy that into our environments.
|
||||
因此，这个过程很大程度上取决于软件开发过程，我们会是正在创建我们的应用程序，添加功能，修复bugs等，然后更新我们的源代码控制和版本控制，同时进行测试。
|
||||
|
||||
### CD
|
||||
进入下一阶段是CD，这更多的是我们通常在任何现成的软件中看到的。如果我们需要从Oracle或Microsoft等供应商那里获得软件，我们将看到一种趋势，从Docker Hub这类仓库中获取这些软件，然后使用我们的CD管道将其部署到我们的环境中。
|
||||
|
||||
Now we have our tested version of our code and we are ready to deploy out into the wild and like I say, the Software vendor will run through this stage but I strongly believe this is how we will all deploy the off the shelf software we require in the future.
|
||||
### CD 持续部署
|
||||
|
||||
It is now time to release our code into an environment. This is going to include Production but also likely other environments as well such as staging.
|
||||
现在我们已经有了代码的测试版本，我们已经准备好进行广泛的部署，正如我上文所说，软件供应商将完成这一阶段，但我坚信这就是我们未来部署所需现成软件的方式。
|
||||
|
||||
|
||||
是时候将我们的代码发布到环境中了。这将包括生产环境，但也可能包括其他环境，如暂存staging。
|
||||
|
||||
Our next step at least on Day 1 of v1 of the software deployment is we need to make sure we are pulling the correct code base to the correct environment. This could be pulling elements from the software repository (DockerHub) but it is more than likely that we are also pulling additional configuration from maybe another code repository, the configuration for the application for example. In the diagram below we are pulling the latest release of the software from DockerHub and then we are releasing this to our environments whilst possibly picking up configuration from a Git repository. Our CD tool is performing this and pushing everything to our environment.
|
||||
|
||||
|
||||
It is most likely that this is not done at the same time. i.e we would go to a staging environment run against this with our own configuration make sure things are correct and this could be a manual step for testing or it could again be automated (lets go with automated) before then allowing this code to be deployed into production.
|
||||
至少在软件部署v1的第一天，我们的下一步是需要确保将正确的代码库拉到(pull)正确的环境中。这可能是从软件仓库（DockerHub）中提取元素，也是可能从另一个代码仓库中提取额外的配置，例如应用程序的配置。在下图中，我们从DockerHub获取最新版本的软件，然后将其发布到我们的环境中，同时可能从Git仓库中获取配置。我们的CD工具正在执行此操作，并将所有内容推送到我们的环境中。
|
||||
|
||||
|
||||
这些很可能不是同时进行的。例如，我们将使用我们的配置进入一个针对此运行的暂存环境，以确保事情是正确的，这可能是一个手动测试步骤，也可能之前实现自动化且可以将此代码部署到生产中。
|
||||
|
||||
Then after this when v2 of the application comes out we rinse and repeat the steps this time we ensure our application + configuration is deployed to staging ensure everything is good and then we deploy to production.
|
||||
|
||||
|
||||
### Why use CI/CD?
|
||||
然后，当应用程序的v2版本发布时，我们重复这些步骤，这一次我们确保我们的应用程序+配置被部署到暂存staging，确保一切正常，然后我们部署到生产中。
|
||||
|
||||
I think we have probably covered the benefits a number of time but it is because it automates things that otherwise would have to be done manually it finds small problems before it sneaks into the main codebase, you can probably imagine that if you push bad code out to your customers then you're going to have a bad time!
|
||||
### 为什么使用CI/CD?
|
||||
|
||||
It also helps to prevent something that we call technical debt which is the idea that since the main code repos are constantly being built upon over time then a shortcut fix taken on day one is now an exponentially more expensive fix years later because now that band-aid of a fix would be so deeply intertwined and baked into all the code bases and logic.
|
||||
我觉得我们已经多次介绍了这些好处，但正是因为它将原来需要手动完成的事情进行自动化了，它可以在加入到主代码库之前发现了一些小问题。你可能可以想象，如果你把坏代码推送给你的客户，这会是多么糟糕！
|
||||
|
||||
### Tooling
|
||||
这也有助于防止我们称之为技术债务（technical debt）的事情，即由于主要代码仓库是随着时间推移而不断构建的，那么有一天做的小修复在几年后会变得更加昂贵，因为现在修复的地方将彻底融入到所有的代码仓库和逻辑中。
|
||||
|
||||
Like with other sections we are going to get hands on with some of the tools that achieve the CI/CD pipeline process.
|
||||
### 工具
|
||||
|
||||
I think it is also important to note that not all tools have to do both CI and CD, We will take a look at ArgoCD which you guessed it is great at the CD element of deploying our software to a Kubernetes cluster. But something like Jenkins can work across many different platforms.
|
||||
与其他章节一样，我们将实操一些CI/CD管道流程的工具。
|
||||
|
||||
My plan is to look at the following:
|
||||
我认为同样重要的是要注意，并不是所有的工具都必须有CI和CD的功能。我们将看看ArgoCD，你可能觉得它在部署软件到Kubernetes集群的CD功能方面非常出色。而像Jenkins这类工具则可以在许多不同的平台上工作。
|
||||
|
||||
我计划关注以下内容：
|
||||
- Jenkins
|
||||
- ArgoCD
|
||||
- GitHub Actions
|
||||
|
||||
## Resources
|
||||
## 相关资料
|
||||
|
||||
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||
- [Introduction to Jenkins](https://www.edx.org/course/introduction-to-jenkins)
|
||||
- [Jenkins.io](https://www.jenkins.io/)
|
||||
- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
|
||||
- [ArgoCD Tutorial for Beginners](https://www.youtube.com/watch?v=MeU5_k9ssrs)
|
||||
@ -118,4 +119,4 @@ My plan is to look at the following:
|
||||
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||
|
||||
See you on [Day 71](day71.md)
|
||||
[第七十一天](day71.md)见。
|
||||
|
||||
@ -1,99 +1,102 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - What is Jenkins? - Day 71'
|
||||
title: '#90DaysOfDevOps - 什么是 Jenkins？ - 第七十一天'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - What is Jenkins?
|
||||
tags: "devops, 90daysofdevops, learning"
|
||||
description: 90DaysOfDevOps - 什么是 Jenkins？
|
||||
tags: 'DevOps, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048745
|
||||
---
|
||||
## What is Jenkins?
|
||||
|
||||
Jenkins is a continous integration tool that allows continous development, test and deployment of newly created code.
|
||||
## 什么是 Jenkins？
|
||||
|
||||
There are two ways we can achieve this with either nightly builds or continous development. The first option is that our developers are developing throughout the day on their tasks and come the end of the set day they push their changes to the source code repository. Then during the night we run our unit tests and build of the software. This could be deemed as the old way to integrate all code.
|
||||
Jenkins是一个持续集成工具，允许对新建的代码进行持续开发、测试和部署。
|
||||
|
||||
|
||||
可以通过夜间构建或持续开发两种方法来实现这些。第一种选择是，我们的开发人员全天都在开发他们的任务，并在当天结束时将他们的更改推送（push）到源代码仓库。然后在晚上，我们运行单元测试并构建软件。这可以被认为是集成所有代码的旧方法。
|
||||
|
||||
The other option and the preferred way is that our developers are still committing their changes to source code, then when that code commit has been made there is a build process kicked off continously.
|
||||
|
||||
|
||||
|
||||
另一种选择也是首选的方式是，我们的开发人员仍在提交他们对源代码的更改，然后当代码提交完成后，构建过程就会不断启动。
|
||||
|
||||
The above methods means that with distributed developers across the world we don't have a set time each day where we have to stop committing our code changes. This is where Jenkins comes in to act as that CI server to control those tests and build processes.
|
||||
|
||||
|
||||
|
||||
上述方法意味着，对于分布在世界各地的开发人员来说，我们每天都没有固定的时间来停止提交代码更改。这就是Jenkins作为CI服务器来控制这些测试和构建过程。
|
||||
|
||||
I know we are talking about Jenkins here but I also want to add a few more to maybe look into later on down the line to get an understanding why I am seeing Jenkins as the overall most popular, why is that and what can the others do over Jenkins.
|
||||
|
||||
|
||||
- TravisCI - A hosted, distributed continous integration service used to build and test software projects hosted on GitHub.
|
||||
虽然我们在这里讨论的是Jenkins，但我也想补充一些内容（也许以后会深入研究），了解为什么我会认为Jenkins是最受欢迎的，为什么会得出这样的判断，以及其他人能在Jenkins上做些什么。
|
||||
|
||||
- Bamboo - Can run multiple builds in parallel for faster compilation, built in functionality to connect with repositories and has build tasks for Ant, Maven.
|
||||
- TravisCI，一种托管的分布式持续集成服务，用于构建和测试托管在GitHub上的软件项目。
|
||||
- Bamboo，可以并行运行多个构建以实现更快的编译，内置与仓库连接的功能，并具有Ant和Maven的构建任务功能。
|
||||
- Buildbot，是一个用于自动化软件构建、测试和发布过程的开源框架。它是用Python编写的，支持跨多个平台分布式并行执行作业。
|
||||
- ApacheGump，专门针对Java项目，旨在每晚构建和测试这些Java项目。确保所有项目在API和功能级别都兼容。
|
||||
|
||||
- Buildbot - is an open-source framework for automating software build, test and release processes. It is written in Python and supports distributed, parallel execution of jobs across multiple platforms.
|
||||
因为我们现在将重点关注Jenkins - Jenkins和上述所有工具一样，是开源的，是一个用Java编写的自动化服务器。它用于通过持续集成实现软件开发过程的自动化，并有助于持续交付。
|
||||
|
||||
- Apache Gump - Specific to Java projects, designed with the aim to build and test those Java projects every night. ensures that all projects are compatible at both API and functionality level.
|
||||
### Jenkins的特性
|
||||
|
||||
Because we are now going to focus on Jenkins - Jenkins is again open source like all of the above tools and is an automation server written in Java. It is used to automate the software development process via continous integration adn faciliates continous delivery.
|
||||
正如你所料，Jenkins有很多功能，涵盖了很多领域。
|
||||
|
||||
### Features of Jenkins
|
||||
**易于安装** - Jenkins是一个独立的基于java的程序，可以与Windows、macOS和Linux操作系统上的软件包一起运行。
|
||||
|
||||
As you can probably expect Jenkins has a lot of features spanning a lot of areas.
|
||||
**轻松配置** - 通过内置的web界面进行设置和配置，包括错误检查和内置帮助。
|
||||
|
||||
**Easy Installation** - Jenkins is a self contained java based program ready to run with packages for Windows, macOS and Linux operating systems.
|
||||
**插件** - 更新中心提供了许多插件，并与CI/CD工具链中的许多工具集成。
|
||||
|
||||
**Easy Configuration** - Easy setup and configured via a web interface which includes error checks and built in help.
|
||||
**可扩展** - 除了可用的插件外，Jenkins还可以通过该插件架构进行扩展，该架构为它的用途提供了几乎无限的选项。
|
||||
|
||||
**Plug-ins** - Lots of plugins available in the Update Centre and integrates with many tools in the CI / CD toolchain.
|
||||
**分布式** - Jenkins可以轻松地在多台机器上分配工作，有助于加快跨多个平台的构建、测试和部署。
|
||||
|
||||
**Extensible** - In addition to the Plug-Ins available, Jenkins can be extended by that plugin architecture which provides nearly infinite options for what it can be used for.
|
||||
### Jenkins的管道pipeline
|
||||
|
||||
**Distributed** - Jenkins easily distributes work across multiple machines, helping to speed up builds, tests and deployments across multiple platforms.
|
||||
|
||||
### Jenkins Pipeline
|
||||
你将会了解这个管道流程，但其还有更广的使用范围，而且我们还没有谈到具体的工具。
|
||||
|
||||
You will have seen this pipeline but used in a much broader and we have not spoken about specific tools.
|
||||
您会把代码提交给Jenkins，然后它将构建您的应用程序，并进行所有自动化测试。接着在每个步骤都完成后进行代码的发布和部署。Jenkins是实现这一过程自动化的工具。
|
||||
|
||||
You are going to be committing code to Jenkins, which then will build out your application, with all automated tests, it will then release and deploy that code when each step is completed. Jenkins is what allows for the automation of this process.
|
||||
|
||||
|
||||
|
||||
### Jenkins的架构
|
||||
|
||||
### Jenkins Architecture
|
||||
首先，不要想着重新造轮子，[Jenkins Documentation](https://www.jenkins.io/doc/developer/architecture/)总是一个开始开始学习的地方，但我也会在这里记下我的笔记和学到的东西。
|
||||
|
||||
First up and not wanting to reinvent the wheel, the [Jenkins Documentation](https://www.jenkins.io/doc/developer/architecture/) is always the place to start but I am going to put down my notes and learnings here as well.
|
||||
Jenkins可以被安装在许多不同的操作系统上，包括Windows、Linux和macOS，也可以作为Docker容器或在Kubernetes中进行部署。[安装Jenkins](https://www.jenkins.io/doc/book/installing/)
|
||||
|
||||
Jenkins can be installed on many different operating systems, Windows, Linux and macOS but then also the ability to deploy as a Docker container and within Kubernetes. [Installing Jenkins](https://www.jenkins.io/doc/book/installing/)
|
||||
当我们开始使用它时，我们可能会考虑在一个minikube集群中安装Jenkins，模拟部署到Kubernetes的过程。但这将取决于我们在本节后续部分中所设置的场景。
|
||||
|
||||
As we get into this we will likely take a look at installing Jenkins within a minikube cluster simulating the deployment to Kubernetes. But this will depend on the scenarios we put together throughout the rest of the section.
|
||||
现在让我们对下面的图像进行拆解。
|
||||
|
||||
Let's now break down the image below.
|
||||
步骤1 - 开发人员提交对源代码仓库的更改。
|
||||
|
||||
Step 1 - Developers commit changes to the source code repository.
|
||||
步骤2 - Jenkins定期检查仓库并提取（pull）任何新代码。
|
||||
|
||||
Step 2 - Jenkins checks the repository at regular intervals and pulls any new code.
|
||||
步骤3 - 构建服务器（build server）将代码构建为可执行文件，在本例中，我们使用maven作为构建服务器。
|
||||
|
||||
Step 3 - A build server then builds the code into an executable, in this example we are using maven as a well known build server. Another area to cover.
|
||||
步骤4 - 如果构建失败，则将反馈发送至开发人员。
|
||||
|
||||
Step 4 - If the build fails then feedback is sent back to the developers.
|
||||
步骤5 - Jenkins将构建应用程序部署到测试服务器，在本例中，我们使用selenium作为测试服务器。
|
||||
|
||||
Step 5 - Jenkins then deploys the build app to the test server, in this example we are using selenium as a well known test server. Another area to cover.
|
||||
步骤6 - 如果测试失败，则将反馈发送至开发人员。
|
||||
|
||||
Step 6 - If the test fails then feedback is passed to the developers.
|
||||
步骤7 - 如果测试成功，那么我们可以将它们发布到生产中。
|
||||
|
||||
Step 7 - If the tests are successful then we can release to production.
|
||||
这个周期是连续的，这使得应用程序可以在几分钟内更新，而不是几小时、几天、几个月和几年！
|
||||
|
||||
This cycle is continous, this is what allows applications to be updated in minutes vs hours, days, months, years!
|
||||
|
||||
|
||||
|
||||
Jenkins的架构中还有很多东西，如果你需要的话，它们有主从功能，可以使主机能够将任务分配到从属Jenkins环境。
|
||||
|
||||
There is a lot more to the architecture of Jenkins if you require it, they have a master-slave capability, which enables a master to distribute the tasks to slave jenkins environment.
|
||||
|
||||
For reference with Jenkins being open source, there are going to be lots of enterprises that require support, CloudBees is that enterprise version of Jenkins that brings support and possibly other functionality for the paying enterprise customer.
|
||||
参考开源的Jenkins，将会有很多企业需要支持，CloudBees是Jenkins的企业版本，为付费企业客户提供支持，并可能提供其他功能。
|
||||
|
||||
An example of this in a customer is Bosch, you can find the Bosch case study [here](https://assets.ctfassets.net/vtn4rfaw6n2j/case-study-boschpdf/40a0b23c61992ed3ee414ae0a55b6777/case-study-bosch.pdf)
|
||||
|
||||
I am going to be looking for a step by step example of an application that we can use to walkthrough using Jenkins and then also use this with some other tools.
|
||||
I am going to be looking for a step-by-step example of an application that we can use to walk through using Jenkins and then also use this with some other tools.
|
||||
|
||||
## Resources
|
||||
博世Bosch就是一个例子，您可以在这里找到博世案例研究(https://assets.ctfassets.net/vtn4rfaw6n2j/case-study-boschpdf/40a0b23c61992ed3ee414ae0a55b6777/case-study-bosch.pdf)
|
||||
|
||||
我将通过一个应用程序示例，我们可以一步步地使用Jenkins进行实操，然后也可以将它与其他一些工具一起使用。
|
||||
|
||||
## 相关资料
|
||||
|
||||
- [Jenkins is the way to build, test, deploy](https://youtu.be/_MXtbjwsz3A)
|
||||
- [Jenkins.io](https://www.jenkins.io/)
|
||||
@ -104,4 +107,4 @@ I am going to be looking for a step by step example of an application that we ca
|
||||
- [GitHub Actions](https://www.youtube.com/watch?v=R8_veQiYBjI)
|
||||
- [GitHub Actions CI/CD](https://www.youtube.com/watch?v=mFFXuXjVgkU)
|
||||
|
||||
See you on [Day 72](day72.md)
|
||||
[第七十二天](day72.md)见。
|
||||
|
||||
Loading…
Reference in New Issue
Block a user