Jenkins指南需要构建，部署，配置和回滚，保留5个版本 [英] Jenkins guide needed for build, deploy, provision and rollback, keeping 5 releases
问题描述
我有一个使用Composer的Git回购的PHP应用程序，有资产，有用户上传的媒体文件，使用Memcache / Redis，有一些代理/工作，并有迁移文件。
到目前为止，我明白我需要创建两个工作在詹金斯
作业1 =构建
作业2 =部署
在 Build job，我将Git repo设置为源代码，我设置了一个post shell脚本，它有一行单行 composer update 。 / p>
1）我的第一个问题与克隆的文件的方式/位置有关。我知道有一个工作区，每次都克隆到那里，或者只有新的东西被拉。
2）作曲家更新接缝一次又一次地加载相同的东西，看起来像没有被缓存多重构建。我很乐意听到这里的意见，但是我期待下一个版本会检查更改，并获得差异。做一个完整的作曲家更新需要几分钟的时间。
在部署作业中，我想设置一个采取最新的稳定版本，并将文件移动到专用文件夹，如 releases2 。然后运行一些配置脚本，最后它将/ htdocs文件夹符号链接更新到新的 releases2 文件夹，因此网络服务器将从该文件夹的网站开始提供服务。 p>
3）如何获取最新的构建（在构建文件夹中，我看到只有几个日志和xml文件，无法从git找到文件）并移动到一个新的目的地
4）如何设置目的地，以便我可以在不同的部署之间保留媒体文件。
5）什么时候处理资产（如发布成功建成后，部署完成之前。
6）什么时候我可以清除缓存（memcache，redis）。
7）如何回滚到上一个版本？我如何设置保持最后5个成功的版本。
8）如何获取失败的构建电子邮件和部署电子邮件警报失败？
9）操作如何获取列表的收件人通过电子邮件成功部署后提交邮件。
我注意到詹金斯有很多插件。不知道这些是否由这些插件处理，但是请随时推荐任何可以完成这些操作的内容。我也读过关于Phing，但是不知道是什么，而且我会用它。
我明白这个主题有很多问题，但是如果你知道回答一些他们请发表回答
warning tl; tr
好的 - 你想要这一切。很多问题 - 长篇故事。
Jenkis是一个连续的集成服务器。
持续集成基本上意味着您不必在开发机器上运行编译和单元测试步骤，而是将其转到中央服务器上，对吧？
由于编译和链接现在位于中央服务器上，所以开发人员有更多的时间来开发，而不是等待编译完成。这就是CI的开始。
现在，在查看PHP项目时，没有涉及任何编译或链接过程。
持续整合工作在PHP项目上的工作归结为只做单元测试，也可能是一些报告生成。
您可以清楚地看到，在查看Jenkins-PHP等帮助项目时，它提供了Jenkins上PHP项目的模板设置 - http://jenkins-php.org/example.html
起始点是Jenkins做某事，在你提交之后资源。
您已经有了Git存储库的配置。它被监视，每当新的提交到达时，就会触发一个新的构建过程。
这个构建过程是什么？
构建过程可以部分地在Jenkis GUI中进行配置。
部分意味着，重点是配置触发器和通知，还有报表生成。报告生成意味着，当某些构建工具完成工作并且日志文件被处理并变成更好的格式时。
例如。当phpunit完成它的工作，可以使用代码覆盖日志，将其转换成一个漂亮的HTML页面，并将其移动到/ www文件夹以供公众查看。）
但，构建过程的大部分实际工作都在构建配置文件中进行了描述。在这里，像Phing，ant（phing的大哥）和nant（win）这样的构建工具发挥作用。
构建工具为脚本编写任务提供了基础。
这是您的自动化发生的地方！
你必须自己编写自动化步骤。
Jenkins只是一个GUI，提供了一些用于显示build.log的按钮，并报告并重新启动构建。
或换句话说：您不能简单地将Jenkins和您的PHP项目粘在一起，希望您可以在GUI上一起单击构建和部署过程。
我们不在，还有！这些工具越来越好，但还有很长的路要走。
让我们来谈谈Jenkis一段时间。让我们专注于构建步骤。
当您仅在CLI上时，如何构建和部署项目？
做吧！您可能需要将简单文本文件中的所有命令和步骤写下来。
现在，将这些步骤转化为自动化步骤。
在项目的根文件夹中创建一个build.xml。
<？xml version = 1.0encoding =UTF-8？>
< project name =project-of-project>
...构建步骤
< / project>
现在我们需要一些构建步骤。
构建工具将它们称为目标。构建目标组任务。
您可以执行自己的每个目标，也可以链接它们。
<？xml version = 1.0encoding =UTF-8？>
< project name =name-of-projectdefault =build>
< target name =build>
<！ - 任务 - >
< / target>
< target name =deploy>
<！ - 任务 - >
< / target>
< / project>
规则：保持目标小 - 一个目标中最多5-7个cli命令。
现在我们来介绍一下依赖关系的目标链接。
假设你的任务构建应该运行phpunit之前。
在CLI上，您将运行 phpunit ，然后执行您的构建命令。
在构建配置中，你必须将调用包装到 exec 任务中。
因此，您创建一个phunit目标，并将其作为依赖关系添加到目标构建中。
依赖关系在指定目标的目标之前执行。
<？xml version =1.0encoding =UTF -8\" >？;
< project name =name-of-projectdefault =build>
< target name =phpunitdescription =使用PHPUnit运行单元测试>
< exec executable =phpunitfailonerror =true/>
< / target>
< target name =builddepends =phpunit>
<！ - 任务 - >
< / target>
< target name =deploy>
<！ - 任务 - >
< / target>
< / project>
像Phing这样的构建工具提供了许多核心任务，如chown，mkdir，delete，copy，移动，exec（...）和其他任务（对于git，svn，通知）。请参阅Phing的文档 http://www.phing.info/docs/master /hlhtml/index.html 或Ant http://ant.apache.org/manual/
Phing的好东西是在构建配置文件中的PHP中编写AdhocTasks并运行它们的可能性。这也可以使用ant，只需构建执行PHP和脚本的exec任务即可。确定 - 快速转发：您在此构建配置中重新创建完整的构建和部署过程。
您现在可以使用独立的目标命令。现在，我们切换回Jenkins CI或任何其他CI服务器并配置它，以运行具有目标任务的构建工具。通常你会有一个默认目标，称为 main 或 build 将所有目标（步骤）链接在一起。 p>
现在，当新的提交到达时，Jenkins通过执行构建脚本启动构建过程。
鉴于这些信息，关于Jenkins如何与构建工具交互，
您的一些问题是自我解释的。您只需创建步骤，以便完成，您想要什么...
让我们开始问答一轮：
Q1：Jenkins工作空间文件夹
工作区是项目所在的地方。新的承诺到达那里。
在高级下，您可以为项目选择工作目录，而无需更改Jenkins主目录。检查使用自定义工作区框，并设置Jenkins将代码放入并构建的目录。
还可以在其中配置构建文件夹以及要保留的构建数量。
Q2：Composer
Composer保留本地缓存 - 它位于$ code> $ COMPOSER_HOME / cache 中。当使用相同的依赖项时，将使用本地缓存。这样可以避免重新下载。如果引入了新的依赖关系或版本更改，那么这些东西将被获取并被重新使用，在 composer install 和 composer update 。
Composer安装/更新始终是从网络或缓存中清除的。
没有保存供应商文件夹。依赖关系被删除并重新安装。
如果需要很长时间，需要很长时间。
如果需要较长时间，请使用Composer一次，然后添加新的构建目标zip-copy-vendor-folder和copy-解压缩供应商的文件夹。我想，你可以想象这些事情做什么。
现在你必须介绍一下如果检查压缩的供应商文件。如果供应商zip文件存在，您跳过作曲家安装目标，然后继续执行copy-unzip ....好的，你知道了。这是一个调整..只有当您的依赖关系非常稳定，并且远远不会经常变化时，这样做。
一般来说，您将需要一个构建目标get-dependencies- with-composer，执行 composer install 。缓存将由Composer自动使用。
Q3：获取最新的版本并移动到新的目的地
最新的版本在构建文件夹中 - 或者，如果您定义了一个移动文件的步骤，它已经在您想要的文件夹中。
Q4：如何获取中的媒体文件
只需添加一个用于将媒体文件夹复制到项目中的构建目标。
Q5：添加资产处理的构建目标
您已经知道这个位置：它是在构建之后。这意味着这是一个部署步骤，对吧？添加一个新的目标，可以通过FTP将您的文件夹上传到您的CDN。
Q6：什么时候我可以清除缓存（memcache，redis）
我建议您使用简单的部署 - 刷新缓存 - 重新缓存缓存策略。
Hotswapping的PHP应用程序很复杂。您必须拥有支持底层组件更改的PHP类，而系统则开始运行两个版本。旧版本淡出缓存，新版本淡入淡出
请单独提出这个问题！
这不像人们想象的那么容易。
这是复杂的，也是Rasmus Lerdorf所喜爱的话题之一。
Q7.1：如何回滚到以前的版本？ >
通过在以前版本的文件夹中运行部署目标/任务。
Q7 .2：如何设置以保持最后5个成功的版本。
Jenkins有一个设置，用于在构建文件夹中保留多少个构建 。
将其设置为5。
Q8：如何获取构建失败的电子邮件和部署电子邮件警报失败？
自动。电子邮件通知是默认的。如果我错了，请查看通知电子邮件。
** Q9：通过电子邮件成功部署后，操作如何获取提醒消息列表。 **
添加一个构建目标send-git-log-via-email-to-operations。
< hr>
我觉得，就像我今天写了一本书...
I am pretty new to Jenkins, and have some sort of understanding but need guidance further.
I have a PHP application on a Git repo, that uses Composer, has Assets, has user uploaded Media files, uses Memcache/Redis, has some Agents/Workers, and has Migration files.
So far I understood I need to create two jobs in Jenkins.
Job 1 = Build
Job 2 = Deploy
In the Build job, I setup the Git repo as source, and I setup a post shell script that has one single line composer update.
1) My first question relates to how/where are the files cloned. I understand there is a Workspace, and every time gets cloned there, or only new things are pulled.
2) composer update seams to load again and again the same stuff, and looks like it's not being cached with multiple builds. I'd love to hear the opinion here, but I was expecting on the next build it will check for changes, and get the diff only. Doing a full composer update takes several minutes.
In the Deploy job, I would love to setup a process that takes the most recent stable build, and moves the files to a dedicated folder like releases2. Then runs some provision scripting and in the end, it updates the /htdocs folder symlink to the new releases2 folder, so the webserver starts to serve from this folder the website.
3) How can I get the latest build (in the build folder I saw only a couple of log and xml files, couldn't locate the files from git) and move to a fresh destination.
4) How shall I setup the destination, so that I can keep Media Files between different deploys.
5) When shall I deal with the Assets (like publishing to a CDN) after successful build, and before deploy is finished. Shall this be a pre/post hook, or a different job.
6) When shall I clear the caches (memcache, redis).
7) How can I rollback to previous versions? And how can I setup to keep last 5 successful releases.
8) How can I get email of failed build and failed deploy email alerts?
9) How can operations get a list of recents commit messages, after a successful deploy by email.
I noticed Jenkins has a lot of plugins. Not sure if these are handled by those plugins, but feel free to recommend anything that gets these done. I also read about Phing, but not sure what is, and were shall I use it.
I understand there are lots of questions in this topic, but if you know the answer for a few of them please post as answer
warning tl;tr
Ok - you want it all. Lot's of questions - long story.
Jenkis is "just" a continous integration server.
Continous integration, basically means that you don't have to run a compilation and unit-testing step on the developer machine, but pull this over to a central server, right? Because compilation and linking is now on a central server, the developer has more time to develop, instead of waiting for compilation to finish. That's how this CI thing started.
Now, when looking at PHP projects, there isn't any compilation or linking process involved. The job of an Continous Integration working on PHP projects boils down to just doing the unit-testing and maybe some report generation. You can clearly see that, when looking at helper projects like Jenkins-PHP, which provdies a template setup for PHP projects on Jenkins - http://jenkins-php.org/example.html
The starting point is "Jenkins does something, after you commited source". You already have a configuration for your Git repository. It is monitored and whenever a new commit arrives, a new "build process" is triggered.
What is this "build process"?
The build process can partly be configured in the Jenkis GUI. Partly means, the focus is on the configuration of "triggers" and "notifications" and also on "report generation". Report generation means, that, when certain build tools have finished their jobs and their log files are processed and turned into a better format.
E.g. when phpunit finished it's job, it's possible to use the code-coverage log, to turn it into a nice HTML page and move it to the /www folder for public viewing.)
But, most of the real work of this build process is described in a build configuration file. Here is, where build tools like "Phing", "ant" (the big brother of phing) and "nant" (win) come into play.
The build tool provides the foundation for scripting tasks. This is where your automation happens! You will have to script the automation steps youself. Jenkins is just a GUI on top of that, providing some buttons for displaying the build.log and reports and re-starting a build, right.
Or in other words: you can't simply stick Jenkins and your PHP project together, hoping that you can click your build and deployment process together on the GUI. We are not there, yet! The tools are getting better, but it's a long way.
Let's forgt about Jenkis for a while. Let's focus on the build steps.
How would you build and deploy your project, when you are on the CLI only? Do it! You might want to write down, all commands and steps involved to simple text file. Now, turn these steps into automation steps. Create a "build.xml" in the root folder of your project.
<?xml version="1.0" encoding="UTF-8"?>
<project name="name-of-project">
... build steps ..
</project>
Now we need some build steps. Build tools refer to them as "target"s. A build target groups tasks. You can execute each target on it's own and you can also chain them.
<?xml version="1.0" encoding="UTF-8"?>
<project name="name-of-project" default="build">
<target name="build">
<!-- tasks -->
</target>
<target name="deploy">
<!-- tasks -->
</target>
</project>
Rule: keep targets small - maximum 5-7 cli commands in one target.
Now let's introduce target chaining with dependencies.
Lets assume, that your task "build" should run "phpunit" before.
On the CLI you would just run phpunit, then your build commands.
Inside a build config you have to wrap calls into the exec tasks.
So, you create a "phunit" target and add this as a dependency to the target "build".
Dependencies are executed before the target specifying them.
<?xml version="1.0" encoding="UTF-8"?>
<project name="name-of-project" default="build">
<target name="phpunit" description="Run unit tests with PHPUnit">
<exec executable="phpunit" failonerror="true"/>
</target>
<target name="build" depends="phpunit">
<!-- tasks -->
</target>
<target name="deploy">
<!-- tasks -->
</target>
</project>
A build tool like Phing provides a lot of core tasks, like chown, mkdir, delete, copy, move, exec (...) and additional tasks (for git, svn, notify). Please see the documentation of Phing http://www.phing.info/docs/master/hlhtml/index.html or Ant http://ant.apache.org/manual/
A good thing with Phing is the possibility to write AdhocTasks in PHP inside the build configuration file and run them. This is also possible with ant, just build a exec tasks executing PHP and the script.
Ok - lets fast forward: you re-created the complete build and deployment procedures inside this build configuration. You are now in the position to use the target commands standalone. Now we switch back to Jenkins CI or any other CI server and configure it, to run the build tool with the target tasks. Normally you would have a default target, called mainor build which chains all your targets (steps) together.
Now, when a new commit arrives, Jenkins starts the build process by executing the build script.
Given these pieces of information, about how Jenkins interacts with a build tool, some of your questions are self-explaining. You just have to create the steps, in order to get done, what you want...
Let's start the Q&A round:
Q1: Jenkins workspace folder
Workspace is where the projects live. New commits arrive there. Under "Advanced" you select a working directory for the projects without changing the Jenkins home directory. Check the "Use custom workspace" box and set the directory that Jenkins will pull the code to and build in. It's also possible to configure the build folders there and the amount of builds to keep.
Q2: Composer
Composer keeps a local cache - it lives in $COMPOSER_HOME/cache. The local cache will be used, when the same dependencies are used. This avoids re-downloading them. If a new dependency is introduced or the version changed, then that things gets fetched and will be re-used, on composer install and composer update.
Composer installs/updates are always fresh from the net or the cache. There is no keep alive of the vendor folder. The dependency is deleted and re-installed. If it takes long, it takes long. End of the story.
If it takes to long, use Composer one-time, then add new build targets "zip-copy-vendor-folder" and "copy-unzip-vendor-folder". I guess, you can imagine what these things do. Now you have to introduce a if check for the zipped vendor file. If the vendor zip file exists, you skip the composer install target and proceed with "copy-unzip.." .. ok, you got it. This is a tweak.. do this only if your dependencies are pretty stable and far from changing often.
In general, you will need a build target "get-dependencies-with-composer", which executes composer install. Cache will be used automatically by Composer.
Q3: get the latest build and move to a fresh destination
The latest build is in the build folder - or, if you defined a step to move the file, it's already in your desired folder.
Q4: how to get media files in
Just add a build target for copying the media folders into the project.
Q5: add a build targets for asset handling
You already know the position: it's "after build". That means it's a deployment steps, right? Add a new target to upload your folder maybe via FTP to your CDN.
Q6: when shall I clear the caches (memcache, redis)
I suggest to go with a simple: "deploy - flush cache - rewarm caches" strategy.
Hotswapping of PHP applications is complicated. You have to have a PHP class supporting the change of underlying components, while the system starts running two versions. The old versions fades out of cache, the new versions fades in. Please ask this question standalone! This is not as easy as one would think. It's complicated and also one of the beloved topics of Rasmus Lerdorf.
Q7.1: How can I rollback to previous versions?
By running the deploy target/tasks in the folder of the previous version.
Q7.2: And how can I setup to keep last 5 successful releases.
Jenkins has a setting for "how many builds to keep" in the build folder. Set it to 5.
Q8: How can I get email of failed build and failed deploy email alerts?
Automatically. Email notifications are default. If i'm wrong, look into notifiers "email".
**Q9: How can operations get a list of recents commit messages, after a successful deploy by email. **
Add a build target "send-git-log-via-email-to-operations".
i feel, like i wrote a book today...
这篇关于Jenkins指南需要构建，部署，配置和回滚，保留5个版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
