Code / Build Release Schedule

oo7ml used Ask the Experts™

I am doing some work for a client and i've hit a bit of a wall with their development team. I want to run a few new UI tests on their site etc... however their development team said they only publish new builds / updates once every 4 weeks.

I was quite shocked at this. The site has about 4000 hits a day, so it is not a major site.

I know Facebook push code three times a day, and i know they are not Facebook... but how often do you think you should push code... OR maybe i should ask what should your Dev setup allow you to push code at, as all sites and businesses are different.

They are telling me that there is absolutely no way they could push code once a week even... any ideas as to why this could be as i doubt i'll get a clear answer.

Thanks in advance for your help.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
ste5anSenior Developer

So, what is the problem with that schedule? Too tight, too loose?


Ideally i would like to push small updates every day, so that we can split test and analyse the results. 4 weeks is far too long.

Most top tech companies roll out a few times a day, however i understand they probably have more resources.
ste5anSenior Developer
What kind of tests?

A/B? Then having too much changes a day is problematic due to correlation.

When it's about functional test, then you need a test/qm-system. Here you may push as fast as you wish, put pushing the same speed to production seems to be too much (without more context).
CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

Most Valuable Expert 2011
Top Expert 2016
New builds every 4 weeks is simply unworkable in a development environment.  I would say that there is something terribly wrong in their build strategy, and it would be my first priority to fix that if I were the boss of them.

Here's a thought...

Set up a Virtual Machine on your own desktop.  You can do this yourself, or you can download some pre-configured systems from Bitnami.  Vagrant is good.  Any system that allows you to deploy coding changes quickly and unit-test the code repeatedly is going to be helpful.  Make sure that your VM closely mirrors the real-life environment.

In that kind of VM environment, you can checkout a branch, make your code and tests, run and re-run the tests and exercise the code to your heart's content.  All this can happen without having to push a single line back to the repository.  When all the unit test pass (or when code review is complete) you can push the changes back to the appropriate origin branch and merge the branches.

This should make your work somewhat independent from the client build schedule.
Sina MaySenior Product Master of Disaster
Getting your environment in a state where you are able to provide "continuous delivery" (which is what Facebook uses), actually takes a lot of preparation.

The company would need to provide support for several areas in order to support the rapid releases that many larger companies have transitioned to.

The first is build automation and continuous integration:
This stage of the development pipeline includes being able to constantly build from a "master" repository while simultaneously being able to share updates to that master repository with any in progress development (Git is a great version control option). It is also very helpful at this stage to have unit testing available to ensure code health and keep your regressions under control. Integrating a service like Bitbucket can help with the deployment of updates to the necessary environments.

The next important area is test automation:
Each new version of an application needs to be tested to ensure you aren't introducing code that you'll later have to rollback or rework into your releases. This stage can start off with manual testing, but in order to allow your testers to focus on new functionality, having automated tests available is a great way to improve productivity and focus. At our office, we've built critical suite testing into our deployments so they can be run in each development environment and on each merge to master. However, it's important to note that building these initial suites can be a time consuming task depending on the breadth of your functionality.

Finally, we can address deployment automation:
Once your code is in a good place, you're ready to send it out to production. If the previous steps have been built into your process, this step becomes much more low risk. Typically, you would stage the release to a subset of servers and then switching over your network traffic to the new code base (i.e. blue green deployments).

Hopefully this helps your understanding of what's needed to transition to a release process like Facebook, and you can figure out baby steps together to get the client releasing more often.
Most Valuable Expert 2011
Top Expert 2016

Sorry I forgot about this, but it's worth a look.  If you're not following this model, you might want to try at least a thought experiment.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial