Well, probably. Realistically, you should be thinking twice before making any code changes after the freeze. Bugs should have to pass some severity test, more so if the fix requires potentially-dangerous changes to the codebase or invalidates the testing that's been done. If you're not doing that, then yeah, you're just deluding yourselves.
But if you're not gonna fix any bugs, then freezing the code is kinda pointless: just build and ship it.
Ultimately, what matters is that you all understand what's meant by the label, not the label itself. One big happy Humpty-Dumpty...
We use the term "Feature Complete". All the features are coded and functional, but we're heading into a test pass to confirm that there are no bugs. If there are bugs, we will find them, fix them, and retest. After we're satisfied with the result, we're "Code Complete".
I think, actually, that they are more correct in their interpretation. A feature freeze, to me, would be a halt to introducing new features, but features currently under development could continue to completion or you could schedule some refactoring work to remove technical debt without generating new features. A code freeze brings a halt to all new development, including refactoring -- the only new code allowed is that to fix bugs found during QA. The latter seems to be what your team is doing.
Some people who get into adaptive and agile engineering methodologies like scrum may not realise what you have gotten yourselves into.
The reason for being agile engineering is releasing to your customers whatever that is usable now and gradually build up its usability and features.
If your project is projected to complete in 18 months but if you could have increasingly something usable every 2 months - why not release features every two months rather than wait till the grand holy day 18 months away since either way the project would still last 18 months.
Your customers' requirement might change so giving your customers opportunity to change their mind frequently, before it's too late, results in exhilarated customers.
Someone might release open source module of one of your modules 10 months from now and then you don't have to do much else but integrate that module.
Therefore, scrummers, or at least scrum masters and/or project managers/architects are required by the dynamics of scrum to modularise ... modularise is not good enough; but granularise the project.
You have to granularise your modules to the right size and provide a contract-interface specification for each so that changes within a module is managed within a module. If your module by itself or due to dependence of other modules is unable to satisfy a contract-interface, you have to code-freeze to enable you to broadcast a contract-interface version 1 so that other teams could continue albeit with less than expected features in the next general product release.
A code freeze is a code freeze.
If your code freezes are experiencing frequent thawing delays, your scrum master and product architect are not communicating or not doing their jobs properly. Perhaps, there's no point in trying to impress or acquiesce to your management that they are using some industry fad called agile programming. Or management needs to hire architect and scrum master who are able to design and granularise the project within the skills of the team as well as the expectations of the customers and the technological constraints of the project.
I think there are management elements and their scrum master who do not realise how crucial a good architect is even for a scrum environment and refuse to hire one. A good architect who is able to listen and work with the team is invaluable to the scrumming process because he/she has to constantly adapt the architecture to changing granularities and expectation.
I also think there are management elements and their scrum master who belongs to the other spectrum of the programming universe due to bad experiences with longer development cycles like waterfall, who therefore think that scrum is meant to produce a product within a month and therefore meticulous investigation into cross-modules effects is not really necessary. They sit down, wet their fingers in the air and come up with a great sprint.
If your team is experiencing frequent thawing of code freezes, you guys might need to code-freeze your whole project and rethink your strategy and see that the cause is due to your refusal to define module contracts that fit the granularity of modules. Or are you guys defining module contracts at all to so that features of a stuck module could be currently rarefied to enable other teams or modules to continue.
Do you guys have a UML strategy that aids in discovering the projected features of a project release and allows you to see the effects of a stranded module and then see which module needs focus to reach a desired product release level? Are you attending scrums and sprints and you have no picture of an UML to show how advanced or delayed you are so that you are just bumping yourselves along happily or otherwise blindly? Or does your scrum master would say to room of yeas or nays, hmm ... that module seems important - without actually having a clear picture of which are the most strandable modules in relation to a product release.
A product release code-freeze is achieved by progressive freezing of modules. As soon as a module is completed, a product test is done to ensure that the module satisfies its contract and that module is code-frozen to say version 2.1. Even though work progresses on that module for 2.2, the project on the whole should not depend on 2.2 but on 2.1. The strategy is to minimise the number of modules whose contracts needs to thawed when a product release is tested and if the product release should scale down its features. If progressive modular freezing does not help your development team ... either the product is so complex and your management is under-expecting the number of iterations to achieve a proper release or the modular architecture and strategy needs serious rethinking.
I have worked on a project (waterfall) in which we had feature freeze AND code freeze.
Feature freeze means the beginning of a bugfix period. Also new branch was created for the new version so that we could implement features, i.e. this is the point when the company starts to work on the new version. No new features are implemented, only bugs are fixed.
Code freeze comes when QA thinks the product is in releasable condition (i.e. they do not know of any severe bugs). Before a final test cycle a code freeze is announced (remember a test cycle might take a week). If the test succeeds this becomes the released product. If it fails then the new bugs are fixed. These checkins are supervised by architects and managers and the risk of every line is practically documented. Then the testcycle is started again.
Summary: After feature freeze you can only check in bugfixes. After code freeze you can only check in in exceptional cases.
If the code isn't broken/messy you wouldn't touch it, and if it is then you will fix it. That's exactly the same situation as if you were not in code freeze. Yes, it's "requirement freeze" or "integration break" which are anti-patterns. It is a point at which to stop including new features in the next release, which is valuable in the sales/marketing/customersupport side of things. But they should probably call it "prerelease".
What ought to happen is that there are always a few releasable versions of the system in version control, and the company picks one to ship.
In your comment, you mentioned the word 'sprint'. That tells me you may be using Scrum(or any other Agile) methodology. In Scrum you hardly 'freeze' anything :) Flexibility, risk identification and mitigation, and above all, in terms of engineering, continuous integration matter a lot in Scrum.
Given this, the team should be cross-functional and the code will be continuously integrated. As a result, you may not have things like 'code freeze'. You just have a releasable product at the end of the sprint. It should have been tested continuously and you should have already got the bug reports which you should have fixed already.
Well, this is theory. However, good scrum teams aren't too far from theory, as scrum is mainly about principles. There aren't too many rules.
I personally won't split too many hairs on the terminology, but the intention behind the term. Most certainly, the term is used to identify a stage in the SDLC, in your organization. Speaking strictly as per Scrum, it doesn't have a bug fix phase. In case you're dedicating one or more sprints to fix bugs, then this term can mean, "no feature backlogs will be included in the sprint, but only bug fixes". This can be easily handled at the sprint planning (and pre-planning) meeting(s) and the team doesn't even have to worry about the terminology. Even better, this terminology/intention doesn't even have to go beyond the Product Owner.
While "Code Freeze" may have a clouded meaning and is, as has been mentioned, more aptly a "Feature Freeze" when considering individual projects/releases it DOES have a place in a larger, integrated deployment where another entity is responsible for packaging and/or deploying multiple software releases from various teams. "Code Freeze" gives them time to make sure the environments are lined up and all packages accounted for. "Code Freeze" also means that nothing but "show stopping" changes are getting in. Everything else would be handled in the next maintenance release.
In a perfect world, scripted testing would have completed before this point and there would have been time allowed for deployment of any last fixes and retest. I have yet to see this happen at any "globo-corp". The (business) testers test up until and even after deployment and the "Code Freeze" becomes a signal to them to step up their efforts and log everything that they've been sitting on. In some cases, it's a signal for them to START testing.
Really, "Code Freeze" is just business speak for "Here there be Tygers". ;-)
when we code freeze, the repo is locked, hopefully all the bugs are fixed that you intended to be fixed, and you the testers to a whole nother round of testing before branching and building to production. if there's any outstanding bugs scheduled for this iteration the leads will be breathing down your neck until it is closed out, or deemed noncritical and pushed back an iteration. so, yes, its really frozen.
发布评论
评论（9）
是的。
嗯，可能吧。实际上，在冻结后进行任何代码更改之前，您应该三思而后行。错误应该必须通过一些严重性测试，如果修复需要对代码库进行潜在危险的更改或使已完成的测试无效，则更是如此。如果你没有这样做，那么，是的，你只是在自欺欺人。
但如果您不打算修复任何错误，那么冻结代码就毫无意义：只需构建并发布它即可。
最终，重要的是你们都理解标签的含义，而不是标签本身。一大快乐的矮胖子……
Yes.
Well, probably. Realistically, you should be thinking twice before making any code changes after the freeze. Bugs should have to pass some severity test, more so if the fix requires potentially-dangerous changes to the codebase or invalidates the testing that's been done. If you're not doing that, then yeah, you're just deluding yourselves.
But if you're not gonna fix any bugs, then freezing the code is kinda pointless: just build and ship it.
Ultimately, what matters is that you all understand what's meant by the label, not the label itself. One big happy Humpty-Dumpty...
我们使用术语“功能完整”。所有功能均已编码并可正常运行，但我们正在进行测试以确认不存在错误。如果存在错误，我们将找到它们、修复它们并重新测试。当我们对结果感到满意后，我们就“代码完成”了。
We use the term "Feature Complete". All the features are coded and functional, but we're heading into a test pass to confirm that there are no bugs. If there are bugs, we will find them, fix them, and retest. After we're satisfied with the result, we're "Code Complete".
事实上，我认为他们的解释更为正确。对我来说，功能冻结将停止引入新功能，但当前正在开发的功能可以继续完成，或者您可以安排一些重构工作以消除技术债务，而不生成新功能。代码冻结会停止所有新开发，包括重构——唯一允许的新代码是修复质量检查期间发现的错误。后者似乎是您的团队正在做的事情。
I think, actually, that they are more correct in their interpretation. A feature freeze, to me, would be a halt to introducing new features, but features currently under development could continue to completion or you could schedule some refactoring work to remove technical debt without generating new features. A code freeze brings a halt to all new development, including refactoring -- the only new code allowed is that to fix bugs found during QA. The latter seems to be what your team is doing.
一些接触诸如 Scrum 之类的自适应和敏捷工程方法的人可能没有意识到自己陷入了什么困境。
敏捷工程的原因是向客户发布现在可用的任何东西，并逐渐建立其可用性和功能。
因此，scrum 的动态要求 scrummers，或者至少是 scrum master 和/或项目经理/架构师进行模块化……模块化还不够好；但要细化项目。
您必须将模块细化到正确的大小，并为每个模块提供契约接口规范，以便在模块内管理模块内的更改。如果您的模块本身或由于其他模块的依赖而无法满足合约接口，则必须冻结代码以使您能够广播合约接口版本 1，以便其他团队可以继续使用，尽管功能低于预期在下一个一般产品版本中。
代码冻结就是代码冻结。
如果您的代码冻结经常遇到解冻延迟，则说明您的 Scrum Master 和产品架构师没有沟通或没有正确完成他们的工作。也许，试图让你的管理层印象深刻或默许他们正在使用某种称为“敏捷编程”的行业时尚是没有意义的。或者管理层需要聘请架构师和 Scrum Master，他们能够根据团队的技能以及客户的期望和项目的技术限制来设计和细化项目。
我认为有些管理人员和他们的 Scrum Master 没有意识到优秀的架构师对于 Scrum 环境来说是多么重要，因此拒绝雇用一名架构师。能够倾听团队并与团队合作的优秀架构师对于混乱过程非常宝贵，因为他/她必须不断调整架构以适应不断变化的粒度和期望。
我还认为，有些管理人员和他们的 Scrum Master 属于编程世界的另一个范围，因为他们在较长的开发周期（如瀑布）中经历过不好的经历，因此他们认为 Scrum 应该在一个月内生产出产品，因此需要进行细致的调查进入跨模块效果并不是真正必要的。他们坐下来，在空中沾湿手指，然后猛冲过去。
如果你的团队经常遇到代码冻结的解冻，那么你们可能需要对整个项目进行代码冻结，并重新思考您的策略，并发现原因是由于您拒绝定义适合模块粒度的模块契约。或者你们是否定义了模块合约，以便当前卡住的模块的功能可以被稀薄化，以使其他团队或模块能够继续。
你们是否有一个 UML 策略来帮助发现项目发布的预计功能，并允许您查看搁浅模块的影响，然后查看哪个模块需要重点关注才能达到所需的产品发布级别？您是否参加了 scrum 和 sprint，但没有 UML 图片来显示您的进度或延迟程度，因此您只是快乐地前进或盲目地前进？或者你的 Scrum Master 是否会说“是”或“否”，嗯……该模块似乎很重要 - 但实际上并没有清楚地了解哪些是与产品发布相关的最稳定的模块。
产品发布代码冻结是通过逐步冻结模块来实现的。一旦模块完成，就会进行产品测试，以确保该模块满足其合同，并且该模块的代码被冻结为 2.1 版本。尽管 2.2 模块的工作取得了进展，但整个项目不应该依赖于 2.2，而应该依赖于 2.1。该策略是在测试产品版本时以及产品版本是否应缩减其功能时，最大限度地减少其合同需要解冻的模块数量。如果渐进式模块化冻结对您的开发团队没有帮助……要么产品太复杂，并且您的管理层低于预期实现正确发布的迭代次数，要么需要认真重新考虑模块化架构和策略。
Some people who get into adaptive and agile engineering methodologies like scrum may not realise what you have gotten yourselves into.
The reason for being agile engineering is releasing to your customers whatever that is usable now and gradually build up its usability and features.
Therefore, scrummers, or at least scrum masters and/or project managers/architects are required by the dynamics of scrum to modularise ... modularise is not good enough; but granularise the project.
You have to granularise your modules to the right size and provide a contract-interface specification for each so that changes within a module is managed within a module. If your module by itself or due to dependence of other modules is unable to satisfy a contract-interface, you have to code-freeze to enable you to broadcast a contract-interface version 1 so that other teams could continue albeit with less than expected features in the next general product release.
A code freeze is a code freeze.
If your code freezes are experiencing frequent thawing delays, your scrum master and product architect are not communicating or not doing their jobs properly. Perhaps, there's no point in trying to impress or acquiesce to your management that they are using some industry fad called agile programming. Or management needs to hire architect and scrum master who are able to design and granularise the project within the skills of the team as well as the expectations of the customers and the technological constraints of the project.
I think there are management elements and their scrum master who do not realise how crucial a good architect is even for a scrum environment and refuse to hire one. A good architect who is able to listen and work with the team is invaluable to the scrumming process because he/she has to constantly adapt the architecture to changing granularities and expectation.
I also think there are management elements and their scrum master who belongs to the other spectrum of the programming universe due to bad experiences with longer development cycles like waterfall, who therefore think that scrum is meant to produce a product within a month and therefore meticulous investigation into cross-modules effects is not really necessary. They sit down, wet their fingers in the air and come up with a great sprint.
If your team is experiencing frequent thawing of code freezes, you guys might need to code-freeze your whole project and rethink your strategy and see that the cause is due to your refusal to define module contracts that fit the granularity of modules. Or are you guys defining module contracts at all to so that features of a stuck module could be currently rarefied to enable other teams or modules to continue.
Do you guys have a UML strategy that aids in discovering the projected features of a project release and allows you to see the effects of a stranded module and then see which module needs focus to reach a desired product release level? Are you attending scrums and sprints and you have no picture of an UML to show how advanced or delayed you are so that you are just bumping yourselves along happily or otherwise blindly? Or does your scrum master would say to room of yeas or nays, hmm ... that module seems important - without actually having a clear picture of which are the most strandable modules in relation to a product release.
A product release code-freeze is achieved by progressive freezing of modules. As soon as a module is completed, a product test is done to ensure that the module satisfies its contract and that module is code-frozen to say version 2.1. Even though work progresses on that module for 2.2, the project on the whole should not depend on 2.2 but on 2.1. The strategy is to minimise the number of modules whose contracts needs to thawed when a product release is tested and if the product release should scale down its features. If progressive modular freezing does not help your development team ... either the product is so complex and your management is under-expecting the number of iterations to achieve a proper release or the modular architecture and strategy needs serious rethinking.
我曾参与过一个项目（瀑布），其中我们有功能冻结和代码冻结。
功能冻结意味着错误修复期的开始。此外，还为新版本创建了新分支，以便我们可以实现功能，也就是说，这是公司开始开发新版本的时间点。没有实现新功能，仅修复了错误。
当 QA 认为产品处于可发布状态（即他们不知道任何严重错误）时，代码就会冻结。在最终测试周期之前，宣布代码冻结（请记住测试周期可能需要一周）。如果测试成功，这将成为发布的产品。如果失败，则新的错误将被修复。这些检查由建筑师和经理监督，每条生产线的风险都有记录。然后再次开始测试循环。
摘要：功能冻结后，您只能签入错误修复。代码冻结后，您只能在特殊情况下签入。
I have worked on a project (waterfall) in which we had feature freeze AND code freeze.
Feature freeze means the beginning of a bugfix period. Also new branch was created for the new version so that we could implement features, i.e. this is the point when the company starts to work on the new version. No new features are implemented, only bugs are fixed.
Code freeze comes when QA thinks the product is in releasable condition (i.e. they do not know of any severe bugs). Before a final test cycle a code freeze is announced (remember a test cycle might take a week). If the test succeeds this becomes the released product. If it fails then the new bugs are fixed. These checkins are supervised by architects and managers and the risk of every line is practically documented. Then the testcycle is started again.
Summary: After feature freeze you can only check in bugfixes. After code freeze you can only check in in exceptional cases.
是的，想太多了。
是的，这是一个用词不当。
如果代码没有损坏/混乱，您就不会碰它，如果是，那么您将修复它。这与您没有处于代码冻结状态时的情况完全相同。是的，“需求冻结”或“集成中断”是反模式。在这个点上，停止在下一个版本中包含新功能，这在销售/营销/客户支持方面很有价值。但他们可能应该称之为“预发行”。
应该发生的是，版本控制中总是有一些系统的可发布版本，并且公司选择一个来发布。
“代码冻结”的精益名称是“浪费”。
Yeah, it's overthought.
Yeah, it's a misnomer.
If the code isn't broken/messy you wouldn't touch it, and if it is then you will fix it. That's exactly the same situation as if you were not in code freeze. Yes, it's "requirement freeze" or "integration break" which are anti-patterns. It is a point at which to stop including new features in the next release, which is valuable in the sales/marketing/customersupport side of things. But they should probably call it "prerelease".
What ought to happen is that there are always a few releasable versions of the system in version control, and the company picks one to ship.
the Lean name for "code freeze" is "waste."
在您的评论中，您提到了“冲刺”这个词。这告诉我您可能正在使用 Scrum（或任何其他敏捷）方法。在 Scrum 中，你几乎不会“冻结”任何东西 :) 灵活性、风险识别和缓解，最重要的是，在工程方面，持续集成在 Scrum 中非常重要。
鉴于此，团队应该是跨职能的，并且代码将不断集成。因此，您可能不会遇到“代码冻结”之类的情况。在冲刺结束时您只有一个可发布的产品。它应该经过持续测试，并且您应该已经收到了应该已经修复的错误报告。
嗯，这是理论。然而，优秀的 Scrum 团队离理论并不遥远，因为 Scrum 主要是关于原则的。没有太多规则。
我个人不会在术语上争论太多，而是在术语背后的意图上争论不休。毫无疑问，该术语用于标识您组织中 SDLC 的阶段。严格来说，根据 Scrum，它没有错误修复阶段。如果您致力于一个或多个冲刺来修复错误，那么该术语可能意味着“冲刺中不会包含任何功能待办事项，而仅包含错误修复”。这可以在冲刺计划（和预计划）会议上轻松处理，团队甚至不必担心术语。更好的是，这个术语/意图甚至不必超出产品负责人的范围。
In your comment, you mentioned the word 'sprint'. That tells me you may be using Scrum(or any other Agile) methodology. In Scrum you hardly 'freeze' anything :) Flexibility, risk identification and mitigation, and above all, in terms of engineering, continuous integration matter a lot in Scrum.
Given this, the team should be cross-functional and the code will be continuously integrated. As a result, you may not have things like 'code freeze'. You just have a releasable product at the end of the sprint. It should have been tested continuously and you should have already got the bug reports which you should have fixed already.
Well, this is theory. However, good scrum teams aren't too far from theory, as scrum is mainly about principles. There aren't too many rules.
I personally won't split too many hairs on the terminology, but the intention behind the term. Most certainly, the term is used to identify a stage in the SDLC, in your organization. Speaking strictly as per Scrum, it doesn't have a bug fix phase. In case you're dedicating one or more sprints to fix bugs, then this term can mean, "no feature backlogs will be included in the sprint, but only bug fixes". This can be easily handled at the sprint planning (and pre-planning) meeting(s) and the team doesn't even have to worry about the terminology. Even better, this terminology/intention doesn't even have to go beyond the Product Owner.
虽然“代码冻结”可能具有模糊的含义，并且如前所述，在考虑单个项目/版本时更恰当地称为“功能冻结”，但它确实在更大的集成部署中占有一席之地，其中另一个实体负责打包和发布/或部署来自不同团队的多个软件版本。 “代码冻结”让他们有时间确保环境已排列好并考虑到所有包。 “代码冻结”还意味着除了“显示停止”更改之外什么都不会发生。其他所有内容都将在下一个维护版本中处理。
在完美的世界中，脚本测试将在此之前完成，并且将有时间部署任何最后的修复和重新测试。我还没有在任何“环球公司”看到这种情况发生。 （业务）测试人员在部署之前甚至部署之后进行测试，“代码冻结”成为他们加大努力并记录他们一直在做的所有事情的信号。在某些情况下，这是他们开始测试的信号。
事实上，“代码冻结”只是“这里有老虎”的商业说法。 ;-)
While "Code Freeze" may have a clouded meaning and is, as has been mentioned, more aptly a "Feature Freeze" when considering individual projects/releases it DOES have a place in a larger, integrated deployment where another entity is responsible for packaging and/or deploying multiple software releases from various teams. "Code Freeze" gives them time to make sure the environments are lined up and all packages accounted for. "Code Freeze" also means that nothing but "show stopping" changes are getting in. Everything else would be handled in the next maintenance release.
In a perfect world, scripted testing would have completed before this point and there would have been time allowed for deployment of any last fixes and retest. I have yet to see this happen at any "globo-corp". The (business) testers test up until and even after deployment and the "Code Freeze" becomes a signal to them to step up their efforts and log everything that they've been sitting on. In some cases, it's a signal for them to START testing.
Really, "Code Freeze" is just business speak for "Here there be Tygers". ;-)
当我们编码冻结时，存储库被锁定，希望所有您想要修复的错误都得到修复，并且测试人员在分支和构建到生产之前进行另一轮测试。如果本次迭代中安排了任何未解决的错误，那么领导者将会紧追不舍，直到它被关闭，或者被认为不重要并推迟迭代。所以，是的，它真的冻结了。
when we code freeze, the repo is locked, hopefully all the bugs are fixed that you intended to be fixed, and you the testers to a whole nother round of testing before branching and building to production. if there's any outstanding bugs scheduled for this iteration the leads will be breathing down your neck until it is closed out, or deemed noncritical and pushed back an iteration. so, yes, its really frozen.