We have 4 different environments:
我们有4种不同的环境:
- Staging
- Dev
- User Acceptance
- Live
We use TFS, pull down the latest code and code away.
When they finish a feature, the developers individually upload their changes to Staging. If the site is stable (determined by really loose testing), we upload changes to Dev, then UserAcceptance and then live.
我们使用TFS,下拉最新的代码和代码。完成功能后,开发人员会将其更改单独上载到Staging。如果站点稳定(由非常宽松的测试确定),我们将更改上传到Dev,然后上传UserAcceptance,然后直播。
We are not using builds/tags in our source control at all.
我们根本没有在源代码控制中使用构建/标记。
What should I tell management? They don't seem to think there is an issue as far as I can tell.
我应该告诉管理层什么?就我所知,他们似乎并不认为存在问题。
8 个解决方案
#1
If it would be good for you, you could become the Continuous Integration champion of your company. You could do some research on a good process for CI with TFS, write up a proposed solution, evangelize it to your fellow developers and direct managers, revise it with their input and pitch it to management. Or you could just sit there and do nothing.
如果它对您有好处,您可以成为贵公司的持续整合冠军。您可以通过TFS对CI的良好流程进行一些研究,编写一个提议的解决方案,将其传播给您的开发人员和直接管理人员,根据他们的输入进行修改并将其推荐给管理层。或者你可以坐在那里什么也不做。
I've been in management for a long time. I always appreciate someone who identifies an issue and proposes a well thought-out solution.
我已经在管理层工作了很长时间。我总是感谢能够识别问题并提出经过深思熟虑的解决方案的人。
#2
Whose management? And how far removed are they from you?
谁的管理?他们离你多远了?
I.e. If you are just a pleb developer and your managers are the senior developers then find another job. If you are a Senior developer and your managers are the CIO types, i.e. actually running the business... then it is your job to change it.
即如果你只是一个pleb开发人员而你的经理是高级开发人员,那么找另一份工作。如果您是高级开发人员,并且您的经理是CIO类型,即实际运营业务......那么您的工作就是更改它。
#3
Tell them that if you were using a key feature of very expensive software they spent a lot of money on, it would be trivial to tell what code got pushed out when. That would mean in the event of a subtle bug getting introduced that gets passed user acceptance testing, it would be a matter of diffing the two versions to figure out what changed.
告诉他们,如果你使用非常昂贵的软件的关键功能,他们花了很多钱,那么告诉什么代码被推出是很简单的。这意味着如果引入了一个微妙的错误,它将通过用户验收测试,那么将两个版本区分开来以找出改变的内容。
#4
One of the most important parts of using TAGS is so you can rollback to a specific point in time. Think of it as an image backup. If something bad gets deployed you can safely assume you can "roll" back to a previous working version.
使用TAGS最重要的部分之一是您可以回滚到特定时间点。将其视为图像备份。如果部署了不好的东西,您可以放心地假设您可以“回滚”到以前的工作版本。
Also, developers can quickly grab a TAG (dev, prod or whatever) and deploy to their development PC...a feature I use all the time to debug production problems.
此外,开发人员可以快速获取TAG(dev,prod或其他)并部署到他们的开发PC ......我一直使用的功能来调试生产问题。
#5
So you need someone to tell the other developers that they must label their code every time a build is done and increment a version counter. Why can't you do that?
因此,您需要有人告诉其他开发人员,他们必须在每次构建完成时标记其代码并增加版本计数器。你为什么不能这样做?
You also need to tell management that you believe the level of testing done is not sufficient. This is not a unique problem for an organisation and they'll probably say they already know. No harm in mentioning it though rather than waiting for a major problem to arrive.
您还需要告诉管理层您认为完成的测试级别不够。对于一个组织来说,这不是一个独特的问题,他们可能会说他们已经知道了。提及它没有坏处,而不是等待一个重大问题到来。
As far as individuals doing builds or automated build processes this depends on whether you really need this based on how many developers there are and how often you do builds.
对于进行构建或自动构建过程的个人而言,这取决于您是否真的需要基于有多少开发人员以及您构建的频率。
#6
What is the problem? As you said, you can't tell if management see the problem. Perhaps they don't! Tell them what you see as the current problem and what you would recommend to fix the problem. The problem has to of the nature of "our current process has failed 3 out of 10 times and implementing this new process would reduce those failures to 1 out of 10 times".
问题是什么?正如您所说,您无法判断管理层是否看到了问题。也许他们没有!告诉他们您认为当前的问题以及建议您解决问题的方法。问题必然是“我们目前的流程已经失败了10次,并且实施这一新流程会将这些失败减少到10次中的1次”。
Management needs to see improvements in terms of: reduced costs, icreased profits, reduced time, reduced use of resources. "Because it's widely used best practice" isn't going to be enough. Neither is, "because it makes my job easier".
管理层需要看到以下方面的改进:降低成本,减少利润,减少时间,减少资源使用。 “因为它被广泛使用的最佳实践”是不够的。也不是,“因为它使我的工作更容易”。
Management often isn't aware of a problem because everyone is too afraid to say anything or assumes they can't possibly fail to see the problem. But your world is a different world than theirs.
管理层通常不会意识到问题,因为每个人都害怕说不出话来或者假设他们不可能看不到问题。但是你的世界与他们的世界不同。
#7
I see at least two big problems: 1) Developers loading changes up themselves. All changes should come from source control. Do you encounter times where someone made a change that went to production but never got into source control and then was accidentally removed on the next deploy? How much time (money) was spent trying to figure out what went wrong there?
我看到至少两个大问题:1)开发人员自己加载更改。所有更改都应来自源代码管理。您是否遇到过某人进行了更改而进入生产但从未进入源代码管理然后在下次部署时被意外删除的时间?花了多少时间(金钱)来弄清楚那里出了什么问题?
2) Lack of a clear promotion model. It seems like you guys are moving changes between environments rather than "builds". The key distinction is that if two changes work great in UAT because of how they interact, if only one change is promoted to production it could break there. Promoting consistent code - whether by labeling it or by just zipping up the whole web application and promoting the zip file - should cause fewer problems.
2)缺乏明确的推广模式。看起来你们正在改变环境而不是“构建”。关键的区别在于,如果两个更改在UAT中工作得很好,因为它们之间的交互方式,如果只有一个更改被提升为生产,那么它可能会在那里打破。促进一致的代码 - 无论是通过标记它还是仅通过压缩整个Web应用程序和推广zip文件 - 都应该减少问题。
I work on the continuous integration and deployment solution, AnthillPro. How we address this with TFS is to retrieve the new code from TFS based on a date-time stamp (of when someone pressed the "Deliver to Stage" button).
我致力于持续集成和部署解决方案AnthillPro。我们如何使用TFS解决这个问题的方法是根据日期时间戳(当有人按下“Deliver to Stage”按钮时)从TFS检索新代码。
This gives you most (all?) the traceability you would have of using tags, without actually having to go around tagging things. The system just records the time stamp, and every push of the code through the testing environments is tied to a known snapshot of code. We also have customers who lay down tags as part of the build process. As the first poster mentioned - CI is a good thing - less work, more traceability.
这为您提供了大部分(全部?)使用标签的可追溯性,而无需实际标记。系统只记录时间戳,并且通过测试环境的每次代码推送都与已知的代码快照相关联。我们还有客户在构建过程中放置标签。正如提到的第一张海报 - CI是一件好事 - 工作量少,可追溯性更强。
#8
If you already have TFS, then you are almost there.
如果你已经有TFS,那么你几乎就在那里。
The place I'm at was using TFS for source control only. We have a similar setup with Dev/Stage/Prod. I took it upon myself to get a build server installed. Once that was done I added in the ability to auto deploy to dev for one of my projects and told a couple of the other guys about it. Initially the reception was luke warm.
我所在的地方仅使用TFS进行源代码控制。我们与Dev / Stage / Prod有类似的设置。我自己动手来安装构建服务器。完成后,我添加了为我的一个项目自动部署到开发人员的能力,并告诉其他几个人。最初接待是温暖的。
Later I added TFS Deployer to the mix and have it set to auto deploy the good dev build to stage.
后来我添加了TFS Deployer并将其设置为自动部署好的开发构建到舞台。
During this time the main group of developers were constantly fighting the "Did you get latest before deploying to Stage or Production?" questions; my stuff was working without a hitch. Believe me, management and the other devs noticed.
在此期间,主要的开发人员一直在与“在部署到舞台或制作之前你有没有最新消息?”进行斗争。问题;我的东西工作没有任何障碍。相信我,管理层和其他开发者注意到了。
Now (6 months into it), we have a written rule that you aren't even allowed to use the Publish command in visual studio. EVERYTHING goes through the CI build and deployments. When moving to prod, our production group pulls the appropriate copy off of the build server. I even trained our QA group on how to do web testing and we're slowly integrating automated tests into the whole shebang.
现在(进入它的6个月),我们有一个书面规则,你甚至不允许在visual studio中使用Publish命令。一切都通过CI构建和部署。转移到prod时,我们的生产组会从构建服务器中提取相应的副本。我甚至培训了我们的QA小组如何进行网络测试,我们正在慢慢地将自动化测试集成到整个社交网络中。
The point of this ramble is that it took awhile. But more importantly it only happened because I was willing to just run with it and show results.
这漫游的重点是需要一段时间。但更重要的是,它只是因为我愿意与它一起运行并显示结果。
I suggest you do the same. Start using it, then show the benefits to get everyone else on board.
我建议你这样做。开始使用它,然后展示让其他人加入的好处。
#1
If it would be good for you, you could become the Continuous Integration champion of your company. You could do some research on a good process for CI with TFS, write up a proposed solution, evangelize it to your fellow developers and direct managers, revise it with their input and pitch it to management. Or you could just sit there and do nothing.
如果它对您有好处,您可以成为贵公司的持续整合冠军。您可以通过TFS对CI的良好流程进行一些研究,编写一个提议的解决方案,将其传播给您的开发人员和直接管理人员,根据他们的输入进行修改并将其推荐给管理层。或者你可以坐在那里什么也不做。
I've been in management for a long time. I always appreciate someone who identifies an issue and proposes a well thought-out solution.
我已经在管理层工作了很长时间。我总是感谢能够识别问题并提出经过深思熟虑的解决方案的人。
#2
Whose management? And how far removed are they from you?
谁的管理?他们离你多远了?
I.e. If you are just a pleb developer and your managers are the senior developers then find another job. If you are a Senior developer and your managers are the CIO types, i.e. actually running the business... then it is your job to change it.
即如果你只是一个pleb开发人员而你的经理是高级开发人员,那么找另一份工作。如果您是高级开发人员,并且您的经理是CIO类型,即实际运营业务......那么您的工作就是更改它。
#3
Tell them that if you were using a key feature of very expensive software they spent a lot of money on, it would be trivial to tell what code got pushed out when. That would mean in the event of a subtle bug getting introduced that gets passed user acceptance testing, it would be a matter of diffing the two versions to figure out what changed.
告诉他们,如果你使用非常昂贵的软件的关键功能,他们花了很多钱,那么告诉什么代码被推出是很简单的。这意味着如果引入了一个微妙的错误,它将通过用户验收测试,那么将两个版本区分开来以找出改变的内容。
#4
One of the most important parts of using TAGS is so you can rollback to a specific point in time. Think of it as an image backup. If something bad gets deployed you can safely assume you can "roll" back to a previous working version.
使用TAGS最重要的部分之一是您可以回滚到特定时间点。将其视为图像备份。如果部署了不好的东西,您可以放心地假设您可以“回滚”到以前的工作版本。
Also, developers can quickly grab a TAG (dev, prod or whatever) and deploy to their development PC...a feature I use all the time to debug production problems.
此外,开发人员可以快速获取TAG(dev,prod或其他)并部署到他们的开发PC ......我一直使用的功能来调试生产问题。
#5
So you need someone to tell the other developers that they must label their code every time a build is done and increment a version counter. Why can't you do that?
因此,您需要有人告诉其他开发人员,他们必须在每次构建完成时标记其代码并增加版本计数器。你为什么不能这样做?
You also need to tell management that you believe the level of testing done is not sufficient. This is not a unique problem for an organisation and they'll probably say they already know. No harm in mentioning it though rather than waiting for a major problem to arrive.
您还需要告诉管理层您认为完成的测试级别不够。对于一个组织来说,这不是一个独特的问题,他们可能会说他们已经知道了。提及它没有坏处,而不是等待一个重大问题到来。
As far as individuals doing builds or automated build processes this depends on whether you really need this based on how many developers there are and how often you do builds.
对于进行构建或自动构建过程的个人而言,这取决于您是否真的需要基于有多少开发人员以及您构建的频率。
#6
What is the problem? As you said, you can't tell if management see the problem. Perhaps they don't! Tell them what you see as the current problem and what you would recommend to fix the problem. The problem has to of the nature of "our current process has failed 3 out of 10 times and implementing this new process would reduce those failures to 1 out of 10 times".
问题是什么?正如您所说,您无法判断管理层是否看到了问题。也许他们没有!告诉他们您认为当前的问题以及建议您解决问题的方法。问题必然是“我们目前的流程已经失败了10次,并且实施这一新流程会将这些失败减少到10次中的1次”。
Management needs to see improvements in terms of: reduced costs, icreased profits, reduced time, reduced use of resources. "Because it's widely used best practice" isn't going to be enough. Neither is, "because it makes my job easier".
管理层需要看到以下方面的改进:降低成本,减少利润,减少时间,减少资源使用。 “因为它被广泛使用的最佳实践”是不够的。也不是,“因为它使我的工作更容易”。
Management often isn't aware of a problem because everyone is too afraid to say anything or assumes they can't possibly fail to see the problem. But your world is a different world than theirs.
管理层通常不会意识到问题,因为每个人都害怕说不出话来或者假设他们不可能看不到问题。但是你的世界与他们的世界不同。
#7
I see at least two big problems: 1) Developers loading changes up themselves. All changes should come from source control. Do you encounter times where someone made a change that went to production but never got into source control and then was accidentally removed on the next deploy? How much time (money) was spent trying to figure out what went wrong there?
我看到至少两个大问题:1)开发人员自己加载更改。所有更改都应来自源代码管理。您是否遇到过某人进行了更改而进入生产但从未进入源代码管理然后在下次部署时被意外删除的时间?花了多少时间(金钱)来弄清楚那里出了什么问题?
2) Lack of a clear promotion model. It seems like you guys are moving changes between environments rather than "builds". The key distinction is that if two changes work great in UAT because of how they interact, if only one change is promoted to production it could break there. Promoting consistent code - whether by labeling it or by just zipping up the whole web application and promoting the zip file - should cause fewer problems.
2)缺乏明确的推广模式。看起来你们正在改变环境而不是“构建”。关键的区别在于,如果两个更改在UAT中工作得很好,因为它们之间的交互方式,如果只有一个更改被提升为生产,那么它可能会在那里打破。促进一致的代码 - 无论是通过标记它还是仅通过压缩整个Web应用程序和推广zip文件 - 都应该减少问题。
I work on the continuous integration and deployment solution, AnthillPro. How we address this with TFS is to retrieve the new code from TFS based on a date-time stamp (of when someone pressed the "Deliver to Stage" button).
我致力于持续集成和部署解决方案AnthillPro。我们如何使用TFS解决这个问题的方法是根据日期时间戳(当有人按下“Deliver to Stage”按钮时)从TFS检索新代码。
This gives you most (all?) the traceability you would have of using tags, without actually having to go around tagging things. The system just records the time stamp, and every push of the code through the testing environments is tied to a known snapshot of code. We also have customers who lay down tags as part of the build process. As the first poster mentioned - CI is a good thing - less work, more traceability.
这为您提供了大部分(全部?)使用标签的可追溯性,而无需实际标记。系统只记录时间戳,并且通过测试环境的每次代码推送都与已知的代码快照相关联。我们还有客户在构建过程中放置标签。正如提到的第一张海报 - CI是一件好事 - 工作量少,可追溯性更强。
#8
If you already have TFS, then you are almost there.
如果你已经有TFS,那么你几乎就在那里。
The place I'm at was using TFS for source control only. We have a similar setup with Dev/Stage/Prod. I took it upon myself to get a build server installed. Once that was done I added in the ability to auto deploy to dev for one of my projects and told a couple of the other guys about it. Initially the reception was luke warm.
我所在的地方仅使用TFS进行源代码控制。我们与Dev / Stage / Prod有类似的设置。我自己动手来安装构建服务器。完成后,我添加了为我的一个项目自动部署到开发人员的能力,并告诉其他几个人。最初接待是温暖的。
Later I added TFS Deployer to the mix and have it set to auto deploy the good dev build to stage.
后来我添加了TFS Deployer并将其设置为自动部署好的开发构建到舞台。
During this time the main group of developers were constantly fighting the "Did you get latest before deploying to Stage or Production?" questions; my stuff was working without a hitch. Believe me, management and the other devs noticed.
在此期间,主要的开发人员一直在与“在部署到舞台或制作之前你有没有最新消息?”进行斗争。问题;我的东西工作没有任何障碍。相信我,管理层和其他开发者注意到了。
Now (6 months into it), we have a written rule that you aren't even allowed to use the Publish command in visual studio. EVERYTHING goes through the CI build and deployments. When moving to prod, our production group pulls the appropriate copy off of the build server. I even trained our QA group on how to do web testing and we're slowly integrating automated tests into the whole shebang.
现在(进入它的6个月),我们有一个书面规则,你甚至不允许在visual studio中使用Publish命令。一切都通过CI构建和部署。转移到prod时,我们的生产组会从构建服务器中提取相应的副本。我甚至培训了我们的QA小组如何进行网络测试,我们正在慢慢地将自动化测试集成到整个社交网络中。
The point of this ramble is that it took awhile. But more importantly it only happened because I was willing to just run with it and show results.
这漫游的重点是需要一段时间。但更重要的是,它只是因为我愿意与它一起运行并显示结果。
I suggest you do the same. Start using it, then show the benefits to get everyone else on board.
我建议你这样做。开始使用它,然后展示让其他人加入的好处。