In order to have a reliable development process, you must take deployments into consideration. And while using services like Beanstalk or DeployBot are a step ahead of transferring files via FTP, you need more than just tools. If you put a solid, consistent process in place, your entire team and your customers will benefit.
The primary goal of a reliable development process could be summed up as, “No surprises!” And deployments play a critical part in achieving that goal. As Zach Holman puts it:
Your deploys should be as boring, straightforward, and stress-free as possible.
Let’s look at how a regular, consistent deployment process can help your team.
It takes more than bran flakes to promote regularity
The phrase regular process indicates regularity. That means it’s a task your team conducts on a regular basis. This results in familiarity and the lack of surprises alluded to above. If you’re only deploying a huge change to your production environment once every 6 months, guess what? Your deployments will be stress-filled, not stress-free.
There’s a reason why continuous deployment is a goal for many teams. It achieves this regularity and gets your team to deploying more frequent changes of smaller impact. Beanstalk enables this type of process with automated deployments.
For your development, testing, or staging environments, Beanstalk can deploy your changes automatically on each commit or push.
Achieve clarity
As well, the phrase regular process indicates structure. Your team is familiar with this activity in a certain manner. Better yet, if you document your process, there is an artifact to refer to for new team members or those still getting used to how your team does things. This makes it far easier for everyone to be aware of a few important facts:
what was changed
where was it changed
who changed it
The team knows where to get this information because of the structure of your process. And Beanstalk provides plenty of options for how to find these details, ensuring the success of your process.
It’s easy to go back in time
Another advantage of a consistent deployment process is it enables you to think of your site or app in linear terms. You can picture your changes reaching back in time with each deployment highlighting a specific point your project/product’s timeline.
The beauty of this is the ability to go backwards. If things go south, if you introduce some bad code (and you will), rolling back to a point in your timeline is a simple step. Most of us have experienced that sinking feeling moments after overwriting the previous state of a production web server with no means of going back.
Having your code in version control gives you something to go back to in these scenarios. But that’s still a lot of work (rolling back your repo, finding the required files, or deploying from scratch once again). But when you use deployment services that focus on this stuff, rolling back is as simple as deploying the last clean version of your code. If you deploy frequently, rolling back involves a manageable, smaller group of affected files.
Again, Beanstalk enables this ability. Prepare a manual deployment and choose the desired commit to deploy again. Beanstalk will ensure your end destination is modified to resemble the state of your repo at the desired commit. Within seconds, you’re site or app is back to the previously working state.
Time better spent
Last, this consistent deployment process allows your team to make the most of their time. There does not need to be any lengthy investigation with team members asking, “What happened?” Investigation of a specific deployment takes seconds with a deployment service. Those questions above (who, what, where) are answered in a matter of seconds.
Instead, teammates can focus on building that new feature with zero bugs. Or cutting page load times in half. Or deciding which new prototyping tool is best . Or whatev. When the toolset and the process are well known, it leads to a more relaxed environment where team members can focus on the things that matter most to them.
I recently had a conversation with a non-technical customer who ran his own business. He came to us with the statement, “I’m tired of my developers overwriting each other’s work!” We understand that pain — it’s why we build products that we hope make people’s jobs a little bit easier.
But again, it takes more than just good tools. Every developer — and development team — needs to take the time to reflect on and formalize the process. Nothing too crazy … just enough to get the job done each and every time!