Why You Should Kill Code Freezes Before The Holidays

Why You Should Kill Code Freezes Before The Holidays

Not many things are certain in life, but if you’re an engineer one thing you know to be true is that every holiday season there’s something you can’t avoid. It’s not colder weather, family gatherings, or holiday shopping - it’s annual code freezes.

With everyone frantically looking for gifts, online shopping reaches a peak as traffic to websites spikes. It’s very common for engineering teams to start a code freeze prior to a time of known high traffic. While a code freeze is a traditional way to ensure site or app stability during this high-traffic period, it also has significant impacts on development velocity and roadmap progression.

If only there was a better way to not only survive but thrive during high traffic periods.

What is a code freeze?

A code freeze means that no more changes will be made to the code by the developers. This typically happens before the launch of a product or during the holiday season. Once the code is frozen, it should not be changed and the only exception is for critical defects. If there is a critical defect, the change control board should approve of making changes to fix it.

Does it hurt you in the long run?

When you are in a code freeze, code keeps piling up, waiting for the freeze to be over. The longer the freeze, the bigger this stack becomes. This process introduces lots of risks and instability, which can slow down integrations for your team. Teams need to figure out if there are issues on their end or if they are caused by changes in someone else's code.

Another problem with code freezes is the more commits you try to release at a time, the more risky the release is. Unless you give your developers something else to work on (for example planning or design work), which is rare, they’re going to keep creating commits that just aren’t going to get released until after your code freeze. 

This means that the next time you have a release, it’s very risky. In addition, when there is a problem, there is no single part of the source code to blame, making it difficult to figure out what caused it because of the large backlog. With a larger number of commits, it will take the engineering team far longer to look for the error since there are more culprits that could have caused something to go wrong compared to making small and frequent changes.

Shipping high-risk code

One major problem is “racing the train,” which is what happens when your developers and designers know they need to release their work or else they will miss a deadline. This is particularly relevant if the team really needs to make sure whatever they are working on is released before the code freeze. 

Software engineers are then incentivized to cut corners when they want to get their last release out. Too often, developers will add fewer tests, skip manual testing, or not weigh the consequences of merge conflicts they just resolved. Any developer in a rush to get something in is more likely to cause a bug than if they didn't have a pressing deadline.

It breaks your CI/CD pipeline

CI/CD or Continuous Integration/Continuous Delivery is about creating an uninterrupted flow in your software development life cycle. If you are in the process of developing a new coding project, it may not be worth the risk to stop for any reason. For example, if you are at a customer conference showing your new product features, it may not be worth having less stability when it’s critical that your demos work.

It is important to work on different parts of your system at the same time. One way to do this without having a high level of risk is with feature flags.

How feature flags help

Code freezes are created to reduce the risk of releasing bad code. However, companies that are unwilling to invest in tooling and processing that allow for consistent changes are doomed to lag behind. Feature flags are a key deployment puzzle piece that helps engineers safely push to production and decouple pushes from releases.

In this technologically-advanced era, the challenge for organizations is to deal with rapid changes. Developers write code and each new line of code can be a risk. This is why some companies create testing processes to reduce the risk. The challenge is to manage the flow of changes through these tests and keep up with the fast pace of technology.

Though we try to be as expedient as possible, changes to code can take some time. To keep things fast, we group code changes together and put them through the pipeline. However, the more code changes we group, the higher the risk of something going wrong. And once it does go wrong, the pipeline slows and everything is affected.

Feature flags are a great tool for reducing the risk of deploying code changes. They allow for independent testing of code and can reduce the risk of breaking and stopping the CI/CD pipeline. Feature flags reduce risk. When a code change is behind a feature flag, it's more manageable and reduces code change risk to a significantly smaller amount. This avoids breaking and stopping the CI/CD pipeline.

Using feature flags as kill switches

Feature flags not only come in handy during high volume or highly sensitivity times, but they should be used all year long. They promote a strong engineering culture when your team is writing code with them. If something goes wrong, you can turn off the feature easily by using a feature flag as a kill switch. Kill switches are an excellent way to prevent your users from seeing a buggy feature, quickly roll back a feature and troubleshoot issues.

Feature flags give you the power to gradually release your app or website to a select population and minimize your risk during high traffic times. This allows your engineering team to ship with confidence and minimizes the risk of buggy code being shown to your users.

Get Started with DevCycle

Use DevCycle feature flags to get rid of the dreaded code freezes. Start your 14-day free trial to see how feature flags can help create a CI/CD pipeline and save your engineering resources.