blocks|key|301817|text|许多公司使用项目日程安排应用程序，如MS+Project。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|301818|这里有一个开源项目日程安排应用程序Open+Workbench，您可能会发现它很有用。它有局限性，但我已经用它来管理我的日程安排。|offset|length|301819|entityMap|0|LINK|mutability|MUTABLE|url|http://www.openworkbench.org/^0|0|H|E|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

A lot of companies use a project scheduling application, like MS Project.

Here's an open source project scheduling application, <a href="http://www.openworkbench.org/" rel="nofollow noreferrer">Open Workbench</a>, that you might find useful. It has limitations, but I've used it to manage my schedules.

blocks|key|307071|text|ThoughtWorks+Go看起来就是这样的。我们目前使用的是Maven，但它的功能还不是很完善。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|307072|entityMap|0|LINK|mutability|MUTABLE|url|http://www.thoughtworks-studios.com/go-agile-release-management|1|http://maven.apache.org/^0|0|F|0|W|5|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

<a href="http://www.thoughtworks-studios.com/go-agile-release-management" rel="nofollow noreferrer">ThoughtWorks Go</a> looks the part. We use <a href="http://maven.apache.org/" rel="nofollow noreferrer">Maven</a> at the moment, but still at a fracion of its capabilities.

blocks|key|3250936|text|我真的不明白为什么不能使用Ant+(http://ant.apache.org)来完成某些任务，每个步骤一个任务。由于这些事情的时间安排是手动的，而且每个环境一次只能有一个软件副本，所以似乎没有太多事情要做，只有编写工作流程并让人们来做。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3250937|entityMap|0|LINK|mutability|MUTABLE|url|http://ant.apache.org/^0|I|L|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I don't really see why this couldn't be done using Ant (<a href="http://ant.apache.org" rel="nofollow noreferrer">http://ant.apache.org</a>) with some tasks, one per step. Since the timing of these things is manual and each environment can only have one copy of the software at one time, there doesn't seem to be much to do but code the workflow and letting folks at it.

blocks|key|3250981|text|这个构建和发布系统混合了不同的东西，所以按照你的列表，我会回答：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3250982|3250983|构建完成(使用Maven的CruiseControl)|ordered-list-item|3250984|构建被部署到测试环境(从CruiseControl)|3250985|Testing调用的ant任务完成(手动步骤)+(Maven告诉您这一点)|3250986|如果测试通过部署到UAT否则拒绝构建(如果测试失败，Maven不会结束，不会调用ant部署程序)|3250987|3250988|从现在开始，我们将混合使用ant和bash脚本|3250989|3250990|UAT已完成(手动步骤)如果UAT通过deploy+to+Prod，则拒绝|3250991|否则拒绝构建|3250992|报废之前在Prod|3250993|中的构建|3250994|我们发现最困难的事情是重启应用服务器，因为我们还没有很好的热部署体验，但只有maven、ant和bash可以做到这一点。|3250995|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|13|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|15|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|16|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|18|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1A|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|1B|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|1C|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1D|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|10|$]]

This build and release systems are a mixture of different stuff, so following your list I'll respond:

<ol>
<li>Build completes (CruiseControl with Maven Build)</li>
<li>Build is deployed to a test environment (Ant task, called from CruiseControl)</li>
<li>Testing is completed (manual step) (Maven tells you this)</li>
<li>If testing passes deploy to UAT else reject build (If the tests fail, Maven won't end, no call to the ant deployer)</li>
</ol>

From here on, we do it pretty much with a mixture of ant and bash scripts

<ol start="5">
<li>UAT is completed (manual step)</li>
<li>If UAT passes deploy to Prod else reject build</li>
<li>Retire build previously in Prod</li>
</ol>

The harder thing we've found was to restart our application servers since we haven't had good experiences with hot deployments but it's doable with only maven, ant and bash.

blocks|key|3251027|text|如果您设法使您的测试自动化(取决于您所做的软件类型，没有理由不这样做)，那么您应该能够使用任何持续集成软件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3251028|问题是，每个阶段都可以写成任务，可以一个接一个地执行，这取决于上一个案例的结果。|3251029|例如，我有一个CruiseControl的设置，它完全按照你在这里描述的那样做，测试阶段运行了大量的单元测试(c%2B%2B/qt)，uat的东西是用可测试性驱动程序编写的。|3251030|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If you manage to automate your tests (and depending on what sort of software you do, there's no reason why not), you should be able to use any continuous integration software. 

The thing is, each phase can be written down as tasks that can be executed one after an another depending of what was the result of previous case.

For example, i've had a setup of CruiseControl that does exactly what you describe here, testing phase was running bunch of unittests (c++/qt) and uat stuff was written with testability driver.

blocks|key|301906|text|我使用过一个名为Hudson的基于web的开源工具，并且对它非常满意。它非常擅长管理构建，并且与SVN和ant有很好的集成。唯一需要注意的是，您需要在自己的服务器上托管它。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|301907|entityMap|0|LINK|mutability|MUTABLE|url|http://hudson-ci.org/^0|8|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I've used a web-based open source tool called <a href="http://hudson-ci.org/" rel="nofollow noreferrer">Hudson</a> and have been very happy with it. It's very good at managing builds and has excellent integration with SVN and ant. The only caveat is that you need to host it on your own server.

blocks|key|307182|text|据我所知，没有一个系统可以自动完成你提到的所有任务。您需要编写一些脚本和测试来自动化系统的部署和测试。然后，您可以使用CI服务器将其组合在一起。以下是我的建议：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|307183|307184|使用适合您的平台的脚本语言(例如，Ant、shell脚本、批处理文件)自动执行部署过程。这包括您提到的任务：|ordered-list-item|307185|将二进制文件上载到目标服务器|unordered-list-item|307186|备份system+|307187|发送电子邮件，通过关闭系统、将符号链接更改为指向新版本并将其启动again.|307188|307189|来向用户发出升级警报|307190|​|307191|307192|编写一些测试来验证软件是否在特定环境中工作。您需要能够在UAT和生产服务器上运行这些程序，以验证软件是否已部署并正常运行。|307193|307194|一旦您自动化了这些工作，您就可以使用持续集成服务器来调度这些任务或按需执行它们。我最熟悉的是Bamboo+(我为Atlassian工作)，但我相信CruiseControl和Hudson也有类似的功能。下面是你如何在竹子中做到这一点：|offset|length|307195|307196|为您的UAT部署创建一个新的构建计划，该计划将执行您的部署脚本，然后测试|307197|将决定您希望如何触发构建，方法是：|307198|将其添加为您的主构建的依赖项，以便它在成功的构建上自动运行|307199|使其按计划运行，这样您就可以在夜间手动触发它，在这种情况下，您只需在您希望它处于触发状态时运行它。|307200|307201|307202|307203|307204|配置生成的权限，以便只有授权用户才能将版本部署到您的服务器。|307205|307206|然后，您可以执行相同的操作，并为您的生产部署设置一个构建，但可能只需要手动触发，并且具有更多限制性权限。|307207|entityMap|0|LINK|mutability|MUTABLE|url|http://www.atlassian.com/software/bamboo/|1|http://cruisecontrol.sourceforge.net/|2|http://hudson-ci.org/^0|0|0|1|1|1|1|0|0|0|0|0|0|1A|6|0|21|D|1|2F|6|2|0|0|0|1|1|1|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1V|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1W|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|1X|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|1Y|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|20|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|21|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|22|8|@]|9|@]|A|$]]|$1|S|3|T|5|E|7|23|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|25|8|@]|9|@$X|26|Y|27|1|28]|$X|29|Y|2A|1|2B]|$X|2C|Y|2D|1|2E]]|A|$]]|$1|Z|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]|$1|10|3|11|5|E|7|2G|8|@]|9|@]|A|$]]|$1|12|3|13|5|E|7|2H|8|@]|9|@]|A|$]]|$1|14|3|15|5|H|7|2I|8|@]|9|@]|A|$]]|$1|16|3|17|5|H|7|2J|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|2K|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]|$1|1A|3|Q|5|6|7|2M|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|2N|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|E|7|2O|8|@]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2P|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]]|1I|$1J|$5|1K|1L|1M|A|$1N|1O]]|1P|$5|1K|1L|1M|A|$1N|1Q]]|1R|$5|1K|1L|1M|A|$1N|1S]]]]

As far as I know, there is no single system that will automatically do all the tasks you mention. You need to write some scripts and tests to automate the deployment of your system and its testing. Then you can use a CI server to put it together. Here's what I'd suggest:

<ol>
<li>Automate your deployment process using a scripting language appropriate to your platform (e.g. Ant, shell scripts, batch files). That includes the tasks you mention:

<ul>
<li>uploading the binary to the target server</li>
<li>taking a backup of the system</li>
<li>sending an email to alert users to the upgrade</li>
<li>performing the upgrade by bringing down the system, changing a symlink to point to the new version, and starting it up again.</li>
</ul></li>
<li>Write some tests which can verify that the software is working in a particular environment. You need to be able to run these against your UAT and production server to verify that the software has been deployed and is running correctly.</li>
</ol>

Once you have these things automated, you can use a continuous integration server to schedule these tasks or do them on demand. I'm most familiar with <a href="http://www.atlassian.com/software/bamboo/" rel="nofollow noreferrer">Bamboo</a> (I work for Atlassian), but I'm sure <a href="http://cruisecontrol.sourceforge.net/" rel="nofollow noreferrer">CruiseControl</a> and <a href="http://hudson-ci.org/" rel="nofollow noreferrer">Hudson</a> have similar features. Here's how you'd do it in Bamboo:

<ol>
<li>Create a new build plan for your UAT deployment, which executes your deployment script followed by the tests </li>
<li>Decide how you want to trigger the build, by either:

<ul>
<li>adding it as a dependency on your main build, such that it runs automatically on a successful build</li>
<li>make it run on a schedule, so you get nightly deployments</li>
<li>make it only triggered manually, in which case you just run the build when you want it to be deployed.</li>
</ul></li>
<li>Configure the permissions for the build so only authorised users can deploy versions to your server.</li>
</ol>

You'd then do the same and set up a build for your production deployment, but probably with only manually triggering and with more restrictive permissions.

blocks|key|304302|text|我们用的是一个叫阿利斯泰尔的威尔士老头。就像一种护身符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|304303|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

We use this old Welsh guy called Alistair. Works like a charm.

What do you use to manage the workflow of deploying your application after the build completes? I'm not talking about just the act of getting files on a server, I'm talking about what happens after that. Verification, testing, approval, migration to production, retiring old builds, etc.

Example:

<ol>
<li>Build completes </li>
<li>Build is deployed to a test environment</li>
<li>Testing is completed (manual step)</li>
<li>If testing passes deploy to UAT else reject build</li>
<li>UAT is completed (manual step)</li>
<li>If UAT passes deploy to Prod else reject build</li>
<li>Retire build previously in Prod</li>
</ol>

Any good applications out there that can manage long running build workflows?

Update

I should also mention that I'm looking for tooling that actually implements the workflow and not just to track what state it's in. (Copy build, change build status, send emails, start/stop services, etc)

App build/deployment workflow

单元测试

服务器

在构建完成后，您使用什么来管理部署应用程序的工作流程？我不是在谈论在服务器上获取文件的行为，我是在谈论在那之后会发生什么。验证、测试、批准、迁移到生产环境、淘汰旧版本等。示例：Build完成Build部署到测试完成(手动step)If测试通过deploy to UAT否则拒绝构建 UAT完成(手动step)If UAT...

问应用程序构建/部署工作流
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问应用程序构建/部署工作流EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问应用程序构建/部署工作流
EN