Jenkins指南需要构建，部署，配置和回滚，保留5个版本 [英] Jenkins guide needed for build, deploy, provision and rollback, keeping 5 releases
问题描述
我有一个Git仓库的PHP应用程序，它使用Composer，有资产，有用户上传的媒体文件，使用Memcache / Redis，有一些代理/工作人员，并有迁移文件。
到目前为止，我明白我需要创建两个工作在Jenkins。
工作1 =建立
工作2 =部署
$ c> Build 作业，我设置Git仓库作为源，我设置一个后壳脚本有一行 composer update 。 / p>
1）我的第一个问题涉及到克隆文件的方式/位置。我理解有一个工作区，每次都克隆到那里，或者只有新的东西被拉。
2）作曲家更新接缝一次又一次加载相同的东西，看起来它不是缓存多重构建。我很愿意听到这里的意见，但我期待在下一个版本，它会检查更改，并得到差异只。完成作曲家的完整更新需要几分钟。
在部署作业中，采用最近的稳定版本，并将文件移动到专用文件夹 releases2 。然后运行一些提供脚本，最后，它更新/ htdocs文件夹symlink到新的 releases2 文件夹，因此Web服务器开始从该文件夹的网站提供。
3）我如何获得最新的构建（在构建文件夹中我只看到了几个日志和xml文件，无法从git找到文件），并移动到一个新的目的地。
4）如何设置目的地，以便我可以保持媒体文件在不同的部署之间。
5）我什么时候处理资产（如发布到CDN），在部署完成之后。这将是一个前/后钩，或不同的工作。
6）我什么时候应该清除缓存（memcache，redis）。
7）如何回滚到上一个版本？我如何设置以保持最后5个成功的版本。
8）如何获取失败的构建电子邮件和失败的部署电子邮件警报？
9）操作如何获取列表的recents通过电子邮件成功部署后提交消息。
我注意到Jenkins有很多插件。不确定这些是否由这些插件处理，但随时推荐任何可以完成这些工作。我也读过Phing，但不知道是什么，我应该使用它。
我知道这个话题有很多问题，但如果你知道
警告tl; tr
好的 - 你想要的一切。
Jenkis只是一个连续的集成服务器。
持续集成，基本上意味着您不必在开发计算机上运行编译和单元测试步骤，而是将其推送到中央服务器，对吧？
因为编译和链接现在在中央服务器上，所以开发人员有更多的时间开发，而不是等待编译完成。这是CI的开始。
现在，当看到PHP项目，没有任何编译或链接过程涉及。
进行PHP项目的Continous Integration的工作归结为只进行单元测试和一些报告生成。
你可以清楚地看到，当看到帮助项目，如Jenkins-PHP，它提供了Jenkins上的PHP项目的模板设置 - http://jenkins-php.org/example.html
起点是Jenkins在您提交来源后执行某项操作。
您已经有一个Git仓库的配置。
这是什么构建过程？
构建过程可以部分在Jenkis GUI中配置。
部分意味着，重点是配置触发器和通知以及报告生成。报告生成意味着，当某些构建工具完成其作业并且其日志文件被处理并变成更好的格式时。
例如。当phpunit完成它的工作，可以使用代码覆盖日志，将其变成一个漂亮的HTML页面，并将其移动到/ www文件夹供公众查看。）
但，这个构建过程的大部分真正的工作在构建配置文件中描述。这里是，在那里构建工具，如Phing，蚂蚁（phing的大哥）和nant（win）发挥作用。
构建工具为脚本任务提供了基础。
这是您的自动化发生的地方！
你必须自动化脚本自动化步骤。
Jenkins只是一个GUI的顶部，提供一些按钮显示build.log和报告和重新启动构建，正确。
换句话说：你不能简单地坚持Jenkins和你的PHP项目在一起，希望你可以在GUI上一起点击你的构建和部署过程。
我们不存在，但！
让我们谈谈Jenkis一段时间吧。让我们专注于构建步骤。
当你在CLI上时，如何构建和部署项目？
做吧！你可能想写下来，所有的命令和步骤涉及到简单的文本文件。
现在，将这些步骤转换为自动化步骤。
在项目的根文件夹中创建一个build.xml。
<？xml version = 1.0encoding =UTF-8？>
< project name =name-of-project>
...构建步骤。
< / project>
现在我们需要一些构建步骤。
构建工具将它们称为目标。构建目标组任务。
您可以自己执行每个目标，也可以链接它们。
<？xml version = 1.0encoding =UTF-8？>
< project name =name-of-projectdefault =build>
< target name =build>
<！ - tasks - >
< / target>
< target name =deploy>
<！ - tasks - >
< / target>
< / project>
规则：keep targets small - 一个目标中最多5-7个cli命令。
现在让我们介绍一下依赖关系的目标链。
假设你的任务build应该运行phpunit。
在CLI上，您只需运行 phpunit ，然后运行您的构建命令。
在构建配置中，您必须将调用包装到 exec 任务中。
所以，你创建一个phunit目标并将其添加为目标build的依赖。
依赖关系在目标指定它们之前执行。
<？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>
<！ - tasks - >
< / target>
< target name =deploy>
<！ - tasks - >
< / target>
< / project>
Phing提供了许多核心任务，比如chown，mkdir，delete， move，exec（...）和其他任务（git，svn，notify）。请参阅Phing http://www.phing.info/docs/master/hlhtml/index的文档。 html 或Ant http://ant.apache.org/manual/
Phing的好处是可以在构建配置文件中的PHP中编写AdhocTasks并运行它们。这也可能与ant，只是构建一个exec任务执行PHP和脚本。
确定 - 快速向前：您在此构建配置中重新创建完整的构建和部署过程。您现在可以单独使用目标命令。现在，我们切换回Jenkins CI或任何其他CI服务器并配置它，以运行具有目标任务的构建工具。通常你会有一个默认目标，叫做 main 或 build p>
现在，当一个新的提交到达时，Jenkins通过执行构建脚本启动构建过程。
给出这些信息，关于Jenkins如何与构建工具交互，
一些问题是自我解释。
让我们开始Q& A回合：
Q1：Jenkins工作区文件夹
工作区是项目的所在地。新提交到达那里。
在高级下，为项目选择一个工作目录，而不更改Jenkins主目录。检查使用自定义工作区框，并设置Jenkins将代码拉入并构建的目录。
也可以配置那里的构建文件夹和要保存的构建文件的数量。
Q2：Composer
Composer保存本地缓存 - 它位于 $ COMPOSER_HOME / cache 中。当使用相同的依赖性时，将使用本地缓存。这避免重新下载它们。如果引入了一个新的依赖或者版本发生了变化，那么在 composer install 和 composer update 。
Composer安装/更新总是从网络或缓存中刷新。
没有保存供应商文件夹。依赖关系将被删除并重新安装。
如果需要很长时间，需要很长时间。
如果需要很长时间，请一次性使用Composer，然后添加新的构建目标zip-copy-vendor-folder unzip-vendor-folder。我想，你可以想象这些东西做什么。
现在你必须引入一个if检查压缩的供应商文件。如果供应商zip文件存在，您跳过作曲家安装目标并继续copy-unzip ....确定，你得到它。这是一个调整..只有如果你的依赖是非常稳定，并且远远不能经常更改这样做。
一般来说，你需要一个构建目标get-dependencies- with-composer，它执行 Q3：获取最新版本并移动到新目标 最新的版本是在build文件夹中 - 或者，如果您定义了一个步骤来移动文件，它已经在您想要的文件夹中。 Q4：如何在中获取媒体文件 只需添加一个构建目标即可将媒体文件夹复制到项目中。 Q5：为资产处理添加构建目标 您已经知道位置： 。这意味着它是一个部署步骤，对吧？ Q6：我应该何时清除缓存（memcache，redis） 我建议使用一个简单的：deploy - flush cache - rewarm caches策略。 Hotswapping的PHP应用程序很复杂。您必须有一个PHP类支持底层组件的更改，而系统开始运行两个版本。旧版本从缓存中淡出，新版本淡入。 Q7.1：如何回滚到以前的版本？ 通过在旧版本的文件夹中运行deploy目标/任务。 Q7 Jenkins在构建文件夹中有一个设置为保留多少个版本 。 Q8：如何获取失败的构建电子邮件和部署电子邮件警报失败？ > 自动。电子邮件通知为默认。如果我错了，请查看通知程序电子邮件。 ** Q9：在通过电子邮件成功部署后，操作如何获取提交邮件的列表。 ** 添加构建目标send-git-log-via-email-to-operations。 我觉得，就像我今天写了一本书... 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 In the 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. In the 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. 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. 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. 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 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 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 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 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屋！ composer install 。
请单独提出此问题！
这不像想象的那么容易。
设置为5。
< hr>
Job 2 = DeployBuild job, I setup the Git repo as source, and I setup a post shell script that has one single line composer update.
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.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.
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.
<?xml version="1.0" encoding="UTF-8"?>
<project name="name-of-project">
... build steps ..
</project>
<?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>
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>
mainor build which chains all your targets (steps) together.
$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 install. Cache will be used automatically by Composer.
