开发和生产工作流程
我已经在网上看到了这个问题的一些解决方案，但我仍然很困惑，所以我想我应该向 Stack Overflow 上的聪明人询问这个问题。
我们是一家小型初创公司，目前我们的工作流程是从开发 -> 到开发。生产涉及 ftp-ing 并上传开发代码。
开发代码受到颠覆控制 - 尽管我们没有利用主干/标签/分支，因为我不知道如何最好地使用这种结构。我觉得应该与实时站点无缝集成，不需要我复制粘贴文件夹和文件。
以下是一些细节： - 在 CakePHP + MySQL 上开发 - 主办于 Media Temple (gs) - 开发人员同时使用 Mac OS (Coda) 和 Windows (Dreamweaver)
所以我的问题是：如何设置适当的可扩展工作流程？
I've seen pieces of this problem solved around the net, yet I'm still confused, so I thought I'd ask the smart folks at Stack Overflow about this.
We're a small startup and at the moment our workflow from development -> production involves ftp-ing in and just uploading the dev code.
The dev code IS under subversion control - although we haven't leveraged trunks/tags/branches since I don't have a good idea of how to best use this structure. I feel that there should be a seamless integration with the live site that doesn't require me copy-pasting folders and files.
Here's some details:
- developing on CakePHP + MySQL
- hosted at Media Temple (gs)
- developers use both Mac OS (Coda) and Windows (Dreamweaver)
So my ask is: how do you setup a proper scalable workflow?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您的工作流程似乎适合没有质量检查的小型组织。我建议您投入一些资源到
1) 构建生产版本并制定版本方案，以便您可以准确跟踪您的生产版本。标记每个版本，以便您可以跟踪它。
2) 构建安装程序。不要手动复制文件夹，因为您可能会犯错误。安装程序还可以轻松跟踪生产中出现的问题。
3）在部署之前对生产进行一些质量检查。即使是一点点的质量检查也会有很大的帮助。开发人员不是好的测试人员，因为他们可能对程序的“功能”有偏见。
4）在你真正需要使用分支之前，先不要理会它。只有这样你才会清楚你需要哪种结构。 subversion 红皮书 有一些关于如何构建分支的想法。
Your work-flow seems proper for a small organization which doesn't have QA. I would advice you to invest some resources into
1) Build production releases and have a version scheme so that you can track your production releases accurately. Tag every release so that you can track it.
2) Build an installer. Don't resort to manually copying folders because you could make a mistake. An installer also makes it easy to track when something goes wrong in production.
3) Do some QA on the production before deploying. Even a little QA goes a long way. Developers are not good testers since they might be biased towards the "features" of the program.
4) Don't bother with branches just yet until you actually have to use it. Only then will it become clear which structure you need. The subversion red-book has some ideas on how to structure your branches.
我过去这样做的一种方法是让生产代码实际上成为一个实时颠覆客户端，拉出“生产”分支。
因此，您可以像往常一样在开发分支上进行工作，并且只要准备好，就可以将副本剪切到生产分支。同步生产服务器，您就可以上线了。如果出现问题，您可以随时重新同步到旧版本。
为了额外加分，您可以添加一个临时分支，这样您就可以捕获代码中未更改的所有内容。然后，您将它们添加到部署脚本中，该脚本将根据需要调整生产系统。
One way I've done this in the past is have the production code actually be a live subversion client, pulling out the 'production' branch.
So you do your work as usual on the development branch, and whenever you're ready, you cut a copy to the production branch. Sync the production servers, and you are live. If something goes wrong, you can always resync to the older version.
For extra points, you can add a staging branch, so you can catch all the things that changed that aren't in your code. Then you add them to a deployment script that will adjust the production systems as needed.
我认为要考虑的关键是包含尽可能多的流程和工作流程，以提高代码质量并减少部署工作量。关键是当你的代码库稳定下来后就开始创建其中的一些东西。在早期，当一切都在快速变化时，您将花费更多的时间来更新脚本，而不是使用脚本节省的时间。
我会推荐以下内容：
创建自动构建脚本。可以使用许多不同的技术和脚本语言（我更喜欢 Ant）从源代码管理中提取文件，自动增量版本号、添加标签并创建部署包。这可能需要花费大量的精力来设置和解决开发人员当前正在执行的任务，但从长远来看，这将带来巨大的回报。它应该将您的开发人员从重复的构建任务中解放出来，让他们能够专注于解决您的技术问题。如您所知，开发人员会厌倦一遍又一遍地做同样的事情，当你感到无聊时，你就会开始犯错误。
自动安装。这是一个边际优势，虽然事情仍处于快速发展阶段，但从长远来看，它将释放出可以更好地用在其他地方的资源。至少，您应该有一个安装包和用于部署代码的安装步骤。
暂存环境。您可能会争辩说，除非您的用户群足够大，以至于当您部署代码时生产系统消失时，他们会开始发出尖叫声，否则这不是必需的。拥有一个允许您测试更改而不会让用户群感到不适的系统非常重要。但当然，这也需要一些 QA 工作。在部署之前您肯定需要一些测试。开发人员总是认为他们是对的，并且从未错过任何事情，但他们永远不应该被相信。总是有不同的代码路径或一些他们从未想到的新的点击排列。
备份您的 SVN。这应该是不言而喻的，但我在一家公司工作，我们的源存储库已经两年多没有备份了。您可以通过执行 svndump 进行备份，然后将生成的文件复制到另一个位置。您还可以只备份存储库所在的文件夹，然后在出现问题时进行恢复。
I think the key thing to consider is to include as much process and workflow that will improve the quality of the code and reduce your effort to deploy. The key thing is to start creating some of these things when your code base has settled down. In the early days when everything is changing rapidly you will be spending more time updating scripts than you will be saving with the scripts.
I would recommend the following things:
Create an automated build script. There are many different technologies and scripting languages that can be used (I prefer Ant) to extract your files from source control, automatically increment version numbers, add tags and create the deploy packages. This may take a large amount of effort to setup and unravel the tasks that the developers are currently doing but this will pay off enormously in the long-run. It should free your developers from the repetitive task of building and allow them to focus on solving your technical issues. As you are aware, developers get bored doing the same thing over and over and when you get bored you start making mistakes.
Automated install. This is a marginal advantage while things are still in a rapid development stage but in the long term it will free up resources that could be better spent elsewhere. At the very least, you should have an installation package and installation steps for deploying your code.
Staging Environment. You could argue that this isn't required until your user base is large enough that they start sqawking when the production system goes away when you deploy code. It is important to have a system that allows you to test your changes without discomforting your user base. But of course, this also requires some QA effort. You definitely need some testing before deployment. Developers always assume they are right and have never missed anything but they should never be believed. There is always a different code path or some new permutation of clicks that they never thought of.
Backup your SVN. This should go without saying but I worked for a company where our source repository wasn't backed up for over two years. You can backup by do an svndump and then copying the resulting file to another location. You can also just backup the folders where your repository exists and then restore if problems occur.