Pushing to Production

You tested the code on your local development environment and it works! Time to push it to production, right? Hold on! We all feel the pressure to get things done and bask in the power and glory of solving the unsolvable, but it’s worth taking the time to create a plan before the next fire starts.

Ideally work is done locally, then pushed up the chain to development where the internal team tests, next to staging with the client testing, and finally to production when all the players have signed off on it. It is a noble ideal that I’ve found is much preached, loosely followed, and often fails in the details.

Take the time to write specifications. Early in my career, I inherited a project from another developer who had left for greener pastures. The project was already a year old and everyone who had been in on the kick-off meeting was gone. My task for the project said, “Add event calendar”. That was it. When I asked for more I was told there were no notes and to just make a simple calendar so that is what I did. It turned out the client was expecting a huge list of features including event registration, ticket sales, image gallery, and a waitlist. The quote for “Add event calendar” was $500. Writing specifications and documentation is not fun, but it is oh so necessary. It will save you time. It will save you money.

Has another developer reviewed the code and what if there is only one developer? If you are on your own, sit down with someone else and explain your code in detail. That person does not have to be another developer and sometimes it’s better if they aren’t. The act of explaining forces you to think about your code in a different way and is useful for finding flaws that you might otherwise not have seen. I’ve had many coding problems that had stumped me for hours and were solved by talking through the code with someone else, “and here the event() function is called in the loop which is where it fails… because some idiot actually named the function events() and… that idiot was me.” This was a real world example from my early coding career. I did indeed feel foolish.

Is there a documented list of the web site processes and how will the new code affect those processes? Changing and adding code can have unintended consequences if there isn’t awareness of the whole picture. An added or changed field in a customer object may work fine on the site, but it may also break an API integration. Your code may be a work of poetry, but that doesn’t mean everyone else has perfectly written code. I ran into a situation where the 3rd party API developer had written their code in a way that required the fields to be in a certain order. Why was it done that way? I have no idea, but the API did break when I added a new field to my application.

Each stage of testing needs to have a checklist of quality assurance requirements in addition to verifying that the fancy new feature works. Take the time to create frontend and backend user stories. Can the frontend and backend users still do all the things they could do before the new feature was added? Do all of the integrations still work?

Did you make any database changes? If you imported a database from staging to production, are all the configuration settings correct for the environment? I’ve seen many developers burned by this one. When testing was done internally and by the client on staging everything was perfect and it was all pushed to production. The little detail that was forgotten was there were sandbox/testing values set in the configuration that are required to be able to test on a development or staging environment. Those settings were included in the push which broke the production site. As you may have guessed, this is never a good thing. Everything different between staging and production must be documented.

In the heat of battle we are pushed as developers to get things done as quickly as possible. We know the right way to do things, but often don’t feel like we have the time to do every step. I’d argue that if you push back and insist on taking all the right steps whenever possible, that you will in fact save time and have fewer fires to put out at the end of the day. Make your list and check it twice.