.Net应用程序发布流程和VSS
我们的团队中有大约 20 名应用程序开发人员。
所有应用程序代码都在 VSS 中。
开发人员拥有本地副本并进行更改,然后将文件检查到 VSS。
团队领导将研究代码并从他们的机器上运行它,如果一切看起来不错,他们会将代码移至 QA 服务器。
测试后的 QA 是否批准检查所有文件,发布工程师将从 VSS 获取最新版本并编译并将文件移动到暂存。
UAT 将在暂存中完成,如果获得批准,发布工程师将复制暂存中的所有文件并将其移至生产。
最近,我们在使用这种方法时遇到了问题,因为开发人员在 VSS 即将进行暂存时签入了一些不应该发布到暂存的文件。
我们使用 VS.net 2008 作为 IDE,我们没有团队基础服务器,Visual source safe 是我们的源代码控制数据库。
请建议我们如何改进我们的发布机制。
谢谢
We have around 20 Application developers in our team.
All the application code is in the VSS.
Developers have their local copies and make changes and then check the files to VSS.
Team leads will look into the code and run it from their machines and if everything looks good they will move the code to QA Server.
QA after testing if approves all the files are checked and the release engineer will get latest version from VSS and compile and move the files to staging.
UAT will be done on the staging and if approved, release engineer will copy all the files from staging and move it to Production.
Oflate we are having issues with this approach as developers checked-in some files in the VSS while it was going to staging that were not supposed to be released to staging.
We use VS.net 2008 as IDE we don't have team foundation server and Visual source safe is our Source control database.
Please do suggest how we can improve our release mechanism.
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以在 VSS 中使用标签 -标签发布,这样您就可以随时返回到已知的代码状态。
也就是说,假设您已准备好将某些代码进行 QA - 此时,将整个分支标记为版本号,例如“版本 1.1”。
当需要升级到 UAT/生产时,获取所有标记为“版本 1.1”的项目 - 确保使用完全相同的代码实现一致的 QA 流程。
当您的下一个版本的代码准备好进行 QA 时,将其标记为“版本 1.2”...等等...等等。
但是,您需要决定如何处理错误修复。
You can use labels in VSS - label releases and this way you can alway go back to a known state of code.
That is, suppose you are ready for some code to go into QA - at this moment, label the whole branch to a version numbers, say "Version 1.1".
When it is time to promote to UAT/Production, get all the items labeled "Version 1.1" - ensuring a consistent QA process with the exact same code.
When your next version of the code is ready for QA, label it "Version 1.2"... etc.. etc.. etc.
You will however need to decide how to deal with bug fixes.