用 wget 吧，只要路径与文件一致或者能取到维一文件绝对路径都可以；windows 下也有 wget.exe 工具

就我个人使用 SVN 感觉 SVN 不是一个好的文档管理工具，更不是一个经验分享的平台： 1、所有的文档大部分都是使用 doc 或者二进制文档，每一次变更不会容易被差量识别 2、文档关有结构化也不能解决检索困难问题，我们每月或甚至每天都在输出一系列文档，但很多技术分散在不同文档中，一个个打开搜索很麻烦；特别是几年和积累后。就更加困难；而这些文档再按横向、纵向整理时，发现不同维度组织又太复杂；同时还会又发现类似文档重复分布在不同目录 3、文档推荐怎么做，很多说的是项目分享，可是入库后就鲜为人知了 如何让文档发挥价值是我们思考主要方向：我们如果能用一个平台快速按不同维度细分、筛选、聚合后，给用户最便捷、最有价值资料话，那把文档放在那或放在什么目录不再是一个纠结的问题了；

构建这个是简单也复杂，最简单开发人员提供一个构建脚本，一条命令就可以构建出来，但我们也应该深入分析下面几点： 1、构建脚本是否通用：包括编译工具安装目录不同时，如何自行识别 2、构建环境能否自己部署：或者说可以快速部署出一个新构建环境 3、跨平台编译时，账号密码如何管理——写在脚本中又不安全 4、构建框架要定义：即构建中是否要定义检查、是否要定义与运行单元测试 5、构建工具失败时，如何保障停在错误点，减少排查时间 等等，以后想到再补充吧

这本书读过，是值得学习，有中文版本的。

CI 具体实践：我的理解——简单就是敏捷提倡的 5 个持续（持续构建、持续检查、持续部署、持续测试和持续反馈）。 前面四个不论是 CM 做的还是团队其他角色做，我们都已经很熟悉；而反馈这个是一个要分开看，最简单反馈就是邮件、im 通知；而接下来状态墙。再深入就是要开发平台定制开发决策用的图形化——趋势图、分类统计等 而 “持续” 的基础就是自动化，自动化的基础就是脚本；但脚本也需要不断的优化和通用化，越通用开发工作量越小，配置越简单。 再说一点检查吧：个人感觉配置简单、团队使用顺手、检查反馈快、能满足一定需求等，可以考虑先用；如果花钱买了一个高大上的软件更好，通用检查也可以配合使用——简单说把一个针对工具解决了特定问题，那大而工具全检查时，自然也会少很多； 总之 CI 实践要做也要总结、思考。

呵呵，想去啊，可能不知道上面批不批，呵呵。

有一个问题，你安装步骤中没说你从 SVN 软件的 LIB 目录 拷贝相关 *.so *.dll 到 apache 的 modules 目录，请确认该操作已操作，如果没有，建议还是先做一下吧。

一般情况下做好前三步基本上不会出切换问题，即使用也在第三步排除了； 第四步切换就是是正式业务上线后，服务器或工具承压性（即现网压力）； 如果兼容性好、内存足够、且业务没有内存泄漏话，做正式导换也是水到渠成的事。

Pipeline 插件可能满足你的需求 [img=1393,995]https://wiki.jenkins-ci.org/download/attachments/54723106/bpp1.png?version=2&modificationDate=1340695983000/img][

https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin

我们升级没有这么简单，一次升级需要至少三天： 第一确定升级理由， 第二是确认升级范围，包括升级软件，升级插件范围，备份数据与确认导入数据 第三确定测试内容和部署测试环境，基本功能 、升级功能测试和导入正常环境数据测试 第四部才是安排升级计划与正式部署、切换 升级过程最怕的就是导入原来配置数据后，无法启动或识别；或者原来常用基本功能失效；

对于配置管理这工作我想说的有下面几点： 1、为什么要有配置管理？这个配置管理员自己在问，很多开发人员也会问？ 2、我们在做什么？是改革创新、还是百日维新，或是墨守陈规？ 3、我们想做什么？一如继往、持续优化、还是大刀阔斧 4、我们建议时考虑过别人感受吗？过山车、惧压烦燥、无边苦役、碍手碍脚、无伤大雅 5、我们做的价值? 立杆见影，温水煮蛙，还是温吞水 6、好的产品如何推广？威逼利诱；领导死任务；死缠难打，先立旗杆 7、你想得到什么？领导表扬、一举成名、团队认可 8、你的出发点是什么？群众期待、领导意愿、个人威望 等等，凡事多问自己几个为什么，很多事也就顺了；再难的事也是人做的，适当的手当也必须的，只要是为团队、公司利益有好处。先说这么多了，注意适时休息

理想很美好，现实很骨感： 版本计划一般是比较好建立，特别是一个项目或 一个产品确定后，开发、设计、测试、部署等计划也就明确了；或者说敏捷的一个迭代计划就可以用于定义相关版本计划。但现实是制定这些计划的人员不是配置管理员；这些计划落实执行或管理者是项目经理，配置管理员也只是参与者；计划调整与变更也是常事，配置管理员也无法保障； 变更管理是必须的，它应该包括市场需求、研发需求、故障管理；这些变更应该体现在每一个版本迭代中；但现实却是很多情况存在两种不好现象，一种是新增了功能或需求，变更流程没有记录（我们且叫偷合功能）；还有一个是领导对故障等指标考核，想写或想合又不能合；开发与测试对立，测试提交一堆单子（他们工作业绩），开发拒绝一堆单子（他们减责）；最后是就算一个版本有清淅的功能、故障变更清单，对这些清单验证的只有测试人员，配置管理员不可能看每一行代码和所有文件。 所以说目前配置管理重点工作还是在配置项管理、配置状态报告、配置审计和变更（过程）管理；因为配置管理域就是 CMMI2 级域；版主说的相关内容是 CMMI3 级以上的。配置管理员可以参与其中过程改进，但应该负责领域必须分清；至于领域之间接口确实应该由 EPG 定义清楚。

这些都不是问题 第一个 C++ 编译：你们用什么 IDE 工具开发的？如果是 VC 开发话，该 IDE 自带了 msbuild 或 nmake;cbuild 也有命令行——看 IDE 相关说明就可以 第二个问题：如版主所言，你可以建一个 linux slave;但我更喜欢用 WINDOWS 做 slave,然后通过 ANT 的 FTP SSH telnet ——上载与编译；源码在 WINDOWS 下好做 sonar sourcemonitor 等检查、呵呵

注意到了吗，两个时间差 8 个小时——而中国在第 8 时区；

最简单办法（也是我们在用的），把系统时间改成格林威治时区，即 0 时区；然后重启 hudson,一切如你所愿了。呵呵

-Xms3072m 这个值是不是设置的有一点大，一般设置为-Xms256; -Xmx4096 这个值是否有效要看你的机器内存和操作系统是否是 linux64 位;如果 windows 32 位的话，还是保守的设置为 1536M（具体多少我忘了，应该小于 2G）

这个很简单的，只要在 pre-commit 脚本中使用 “%SVN_BINDIR%\svnlook changed -t "%TXN%" "%REPOS%" | findstr "分支名 1">nul if %errorlevel% EQU 0 goto mangtag “%SVN_BINDIR%\svnlook changed -t "%TXN%" "%REPOS%" | findstr "分支名 2">nul if %errorlevel% EQU 0 goto mangtag :end exit 0 :mangtag %SVN_BINDIR%\svnlook log -t "%TXN%" "%REPOS%" | findstr "ticket 号的特性" > nul if %errorlevel% gt 0 goto end echo "没有关联特征 “ 1>&2 exit 1

这要看你的工性质了，我的 master 独立安装在一台 linux 环境，并行构建最高峰时能达到 30 个每分钟，访问从来没有问题； 我想主要问题是你的 slave 运行引起的，如果你的 slave 构建一次并发构建少于 2 个 job 仍卡的话，可能就是内存不足，如果并发在 3 个以上有卡的话，问题在 IO 也就是你的硬盘读写瓶颈；我有一台 16 核/24G 服务器并发跑 6 个 JOB 时，远程桌面连接该机时就会卡，原因是该编译机是两块硬盘做的是 raid1

我都不停机，直接用 robocopy 进行增量镜像，如果上次拷贝（镜像）失败话，后面镜像还是可以自动修复前面的错；

我们现在 SVN 服务器使用是 VSVN1.1 的——这是一个内核了 HTTP 的 WEB 服务器，经过这么多年使用，发同它存在一个严重的性能问题，第一是它内核的是 32 位 http 应用程序,即使用服务器有 32G 也至多使用到 3.2G，上千用户并发访问时，出现假死情况；第二，该软件有一个 API 总是报 64 位 xx 的错，修改了配置还是不行

现在换到 VSVN2.X 版本时，它与域服务器集成过紧，无法通过自动化脚本进行权限的定义。

不知那位同仁安装过 64 位的版本，相关稳定性如何？或者在 linux 环境 下安装过加域的 SVN，——我在 redhat 上安装成功了 SVN，但加域时却报不认域。哎； 如果有相关经验证的同仁请 mail 给我：[email] pasey@163.com[/email]

建议你们还是换成 ANT 脚本吧，那个看起来直观一点，且可以多平台使用； 以前我有一个同事他就是用 expect 脚本，当出现三层机器间访问嵌套时，脚本就会出现莫明的错话；让我协助排查时，看的好累啊——这主要是它看类清楚的模块化定义，重载式应用都写在一个脚本中，这就要其他人员先要了解这个脚本架构，还要记得每一个函数模块，单步跟踪每一次调用； 同时每一台机器提示符不一样，该脚本不支持从文件获取变量定义——如果一台编译机提示符变化了，脚本就得重写；另外就是这个脚本登录上存莫明问题，不能超时退出——可能与编译机独占有关，但它不会退出导致挂起

这个是一个综合性的问题： 第一就是需求说明、详细设计、开发文档等一系列产品生命周期内文件必须强化配置管理 第二就是强化开发人员代码走查、统一编码规划、测试驱动开发、代码重构建等实践落实 第三就是要求上层领导做好产品的生命周期的规划，明确产品支持服务年限，以及替代产品的开发与宣传；

不知道你是不是否使用了持续集成（自动化构建），如果使用了话，构建版本应该就下载最新或指定构建结点的版本到测试库；

如果开发与测试合作紧密的话，可以实现自动化构建、推送部署、自动化加载测试，你的构建应该就下载指定版本到发布库了；

这里有一点我不认同，自以为聪明的人，重不写测试例，他的聪明使他随心写代码、写出完美的代码，但他如果离开了这个项目、岗位，只有代码，没有功能描述、没有测试保障，只有像天书的代码。天知道后面维护人员会抓狂到什么程度。——以前我觉着一个写出一份完美的代码很了不起，但后来我发现，一个高手绝对是那些能很快支撑维护代码的；他们不仅要有较高的专业知道能力，更需要强大逆向工程分析和 “奇迹般” 的悟性、创造性。 快乐的路大家都喜欢走，但充满挫折与挑战的路少有人问津。先不要问自己创造了多少，问一下自己给别人带去多少麻烦。

个人一点观点：第一为什么要打卡，第二每天打卡上班产能一定能保证吗，第三难道只有打卡才是规范管理？ 要知道作为软件开发行业，不是代码民工，一个 8 个小时，能有 4 个小时专心写代码就相当不错了，其他时间做什么：“课间休息”、吃饭、看书、讨论问题、研究方案。上面都还是好的，那不好的，发呆、玩游戏、做自己事等等； 相反国外一些大的软件 IT 对打卡就没有严格要求，只要你完成好每天计划任务，项目进度，随时可以上班与下班——如 google、 皮克斯

[i=s] 本帖最后由 pasey 于 2013-6-23 07:42 编辑

随便说两句吧： PMP 中强调质量、成本、进度三剑客同样重要，但随着 APPLE 的让用户体验速度一发不可收拾后，现在以客户为中心更是打破了软件业的技术质量为本的传统模式——更倾向于眼球效应，也就是进度，在成本有限下，更推动了产品快速迭代；为什么在功能机时代三星总是进不了前五——那个年代拼的是技术、质量和成本；但进入智能机时代，三星超过苹果——这个拼的是眼球、体验，虽然三星质量不是最好（我用的 note2 PAD 隅尔也会出现个别程序启动很长时间或假死），但更新和体验速度超过任何手机：：：时代变了。

文档重要：在项目管理中，CMMI 更倾向于文档体现产品过程控制，敏捷强调整少量的文档；如果两者结合起来，这迫使我们更加深入分析那些是我们必须的文档——不能简单从文档价值（有时也看不出），不如反过来，如果没有这个文档，会有什么后果，即然可有可无，那就优化掉吧；

KPI 是好东西，它是一个风向标指出项目、产品不足，但中国人把它就变的无法理喻的考核；正如某一个项目自动化测试用例达到 10000 条，但覆盖率只有 1%；同样有些版本测试覆盖率达到了 90% 了，但产品却赔了钱。为什么？为了 90% 覆盖率付出的成本太高，进度也跟不上，在眼球效应今天，kpi 是能够反馈一引起有用信息，但重点是 KPI 定义和它的引导性，而不是考核，否则就出现为做数据而做数据局面——必竟中国人太过于小聪明了。

架构：这个东西好不好，好，这个必须肯定的，没有架构我们为之付出是成本是不可估量的；举一个实在例子，某一个团队没有 SE，由开发人员根据自己知识面在几个月时间做出一个非常好的产品，得到领导认可，可随着业务扩展和使用量的上升，这个产品界面无法跟上需求、数据查询严重滞后等问题暴露出来；当团队研究后发现，不仅开发语言要考虑调整，整个框架都需要重定义（这个损失和工作压力可想而知）；所有架框一定要清楚必须是具有一定专业领域的人做，同时做架框的人必须能及时输出可以用于交流的产出物——UML 图、架构描述文档、架构设置模型和及时沟通确认计划