Why It’s Important to Deploy Early and Often

Plus Plus from Palantir.net

Account Manager Allison Manley is joined by Senior Engineer and Team Lead Bec White who has some thoughts regarding deployment, and why it's so important to do so early and often not only for your internal process but also to help bring a site to life for your clients.
TRANSCRIPT
Allison Manley [AM]: Hi, and welcome to the Secret Sauce, brought to you by Palantir.net. This is our short podcast with a quick tip on some small thing you can do to help your business run better. I’m Allison Manley, an account manager at Palantir, and today’s advice comes to us from Bec White, Senior Engineer and Team Lead, who has some thoughts regarding deployment.
Bec White [BW]: My name is Bec White, and I want to talk about deploying early and often
On a project, I feel It's important to get deployments running as early as possible. There are a bunch of reasons for this, but my two favorites are not solving problems at the last minute, and bringing the site to life for clients.
I mean, number one, I'm not a firefighter. I don't want to solve problems under pressure, I want to solve problems beforehand and then have my team look like wizards later.
There's this idea that with Drupal that you don't have to know the target environment, that you just make a drupal site and then you can put it anywhere.
But in practice, though, there's always something about the environment that always affects the build: whether it’s the php versions, whether it’s setting up http redirects (on apache vs nginx), whether it’s your single sign on integration, search servers, varnish config, just to name a few. And for the Drupal-specific hosts, there are other things, like how the settings.php file is managed, and where the Drupal root lives in the repository.
So always when you run a project on a new environment, there is *something*. You can make as big a launch checklist as you want, but we all know how painful it is to find out these things when you're rolling up on a deadline.
But at the beginning of a project, the deadlines are just thin wisps on the horizon. And under a blue sky, it's not so catastrophic, so stressful when drupal barfs errors all over the destination environment where the client can see them.
Ok, so at the beginning of a project, maybe we have a "sprint zero" and we get a repository set up, and Drupal is installed, and hey — we put it on the staging environment. Then there's a plain Drupal up there: it has a druplicon and has the bartik theme. And you definitely . . . the project isn’t ending there. Just looking at it, we know that we're going to have to deploy again… and again, and again.
As an engineer, I love systems, and I love repeatable workflows. So at this point if I can put together a workflow that my whole team can use, that my junior developers can use to deploy when I’m out on vacation, something that’s going to be robust across the lifespan of the project — that's going to be really gratifying. And the goal is to make things less error-prone — to run everybody's code through the same tests, to manage the dependencies consistently so they are present on all environments, even to prevent development code from being deployed to production environments. Once we've ironed out the wrinkles in the sprint zero deployment, we can evolve the deployment script as the project continues and there are additional requirements that get added to the build.
This is pretty powerful because at this point we have a repeatable deployment. Everything that goes up into this environment, any content and configuration, that anybody does on that staging environment, that little sprint 0 deployment, anything will get wiped away. You can't break anything as a user on this little sprint 0 site.
And when you deploy the sprint 1 work, you're bringing the site to life. Clients can go in and take a poke at their new site, and you know what? The sooner we'll get the feedback that is so crucial to aligning our work with our clients' needs, the better. This is why we do agile!
This is the part where I get really excited. What’s better than having someone look at your work and say, "oh boy, this is going to be great for us." Or even better, "This field isn't working the way I expected" or "this page has a bug".
That sounds like negative feedback, but really the sooner we get that information, the better. Getting that stuff right is foundational for the work we do. Whether we need to explain what we were thinking, fix some code, or reorganize a user interface, it's always easier to incorporate these kinds of fixes earlier in a project. And the only way we’re going to get that kind of feedback is if it’s real to them: if they see it, they can use it, they can interact with it. And production is where it’s going to be real.
I especially love it when a client, someone who is playing the "product owner" role on a project, says, "ooh, let me show this to my marketing director/content author/intern". What this shows me is someone who is invested in the work my team is doing. Someone who recognizes that this project is going to affect the way their organization works. And as an engineer, the only thing better than systems and repeatable workflows is someone who is invested in my work.
So, deploying early and often not only lets us avoid doing high-pressure, last minute, environment-related bug fixing, but it also fosters that feedback cycle that lets us respond to clients.
AM: Thank you, Bec. For more great tips, follow us on Twitter at @palantir, or visit our website at palantir.net. Have a wonderful day!