- November 14, 2013
Automating Your Deployments
- @markhuot
- Development Director
Deploying a website to a web server is hard. Not “It’ll take some extra time” hard or “We’ll need some help” hard.
It’s “Get a whiteboard and plan out the thing A Beautiful Mind-style” hard. It’s easy to look at your code, look at your server, and just drag/drop files to production. It’s a lot more difficult to set up an automated system that will do that for you.
At Happy Cog, we work in a variety of technical situations, and our deployment strategies must be extensible enough to suit each and every need. We deploy to Windows servers and to *nix servers. In some situations, we deploy code as well as content. We deploy PHP websites on some servers and Ruby web workers on others.
Even with all these environments, there is one common theme to all our deployments: ease. In our early deployment days, we struggled quite a bit, because our process included several steps—some automated and some manual. We would constantly push broken sites to testing, because a file wasn’t minified or a link wasn’t updated. As a result, we’ve learned to keep our deployments automatic and effortless.
By deploying automatically, on every code push, we allow everyone on our team a live view into the development process without requiring them to manage a full web stack locally. Typically, we will set up a URL for internal testing to receive this automated deployment. If we’re working in static templates, the deployment will simply copy the files up to the server on each push.
Note: Production deployments are an entirely different animal. Production deployments are higher risk and require more thought and planning. While we still look to retain the same effortless strategies, we do enforce a manual step where the developer must acknowledge the deployment before it may go live. We never use process or added complexity to limit production deployments.
Our live view of the development process allows our QA team to get involved earlier. We don’t have to wait until we deploy to production or package a release. Our QA team can immediately verify if an issue is resolved. Our developers can round out a batch of tickets rather quickly with near real-time feedback from the rest of the team. Our live URL also helps us reference all breakpoints and iterate rapidly in code, instead of in Photoshop.
Lately, we’ve been using Beanstalk to configure our automatic deployments. We can push to our repository, and Beanstalk copies the updated files quickly over SFTP to our server. Sometimes, that’s all we need. Other times, we’ll use Beanstalk to run a script on each deployment. For example, any time we push code, Beanstalk can automatically import a specifically named SQL file into the database. With automatic deployment, we can share URLs and never worry that someone will see outdated content.
Always on, automatic deployments have enabled our teams to work closer together than ever before. Implementations happen quickly and feedback can be given with little friction. These deployments require a bit extra configuration in the beginning, but the result has paid us back many times over.
Looking to learn other methods for site deployment? Check out Ryan Irelan’s recently released course, Deploying Websites, for The Happy Cog Way, then come back and share your own process for going live.