We are constantly improving our approach to code. We build it. We break it. We love it. We hate it. And sometimes we blow it all up and start from scratch. If you caught @alliwagner’s swansong article about our starter files, you can recognize the value in years of iteration. But that doesn’t stop with just code. We’re constantly iterating on process, workflow, content strategy, etc. You name it, we’re always looking for ways to improve it. Nothing is ever set in stone. And the same goes for some of the less glamorous (depending on who you ask) tasks like… how do we put these things on the web for people to see?
We’ve written 2 blog posts about deployment. View all topics »
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.