How does development affect deployment, and how can deployment have an effect on development?
Over the course of the last few months, I’ve started to realize how much emphasis should be placed on the deployment of an application very early in the development process, and I’ve started to put serious thought into how as a developer, I need to make that a painless step.
BIgStompy Corp has a new widget tracking system in the works. They are currently using a spreadsheet and a widget catalog to track all the widgets they have on order, in-stock and being fulfilled. Management starts with identifying what they need in their shiny new WidTrack application.
“We need to be able to enter in a part number and description”
“We need to be able to count how many widgets we have on order”
And so on.
“When you get it close to up and running, we want to see it. We’d also like to roll it out to some of our more experienced staff, so they can make sure it’s all there, and then we aim to put it into place by Q3 this year”
The developers take these requirements.
They decide that they’re going to create tables, they’ve got an idea that they want to use Entity Framework, and they’re going to use (as it fits quite nicely) ASP.NET MVC to develop a nice, friendly front end to WidTrack. They start writing the code. They check it into their repository of choice.
As they proceed through the development, several packages are required, NUnit for testing, json.net for serialization, and all manner of other packages. This is going great, they develop, they check it in to the repository, feature after feature starts to appear. Two months in, they’ve got something worth showing to management. They copy the site to a test server in the office, install the database and get it running. Management love it, they want to start testing this with a couple of users straight away. They copy all the files over to a new staging server, where it’s set on almost immediately by a few users.
Development continues, the team deprecated some packages, updated the version of a few others. Pushes out to the test server happen quite often to show progress. Occasionally these changes are put to the staging server. Cycle continues. One day, the team are told to push it, they like it so much that they have stopped using the old way and are exclusively on WidTrack on the staging server. What was the last version that was pushed to the staging system? What changes did that have? Did that have the huge schema redesign that you needed to do to introduce the “tweet when in-stock” feature? Development slows to a crawl, because now the team has to figure out how to get the newest version updated onto the server.
It’s easy to concentrate on the development. The design was there, the product was there and the users were loving the result. From a development stand-point it was clean, stable and well tested. The downside was that now the development team are scrambling to figure out how to migrate data between schema, how to bring about changes they’ve got no method of identifying.
The deployment of a system seems like pie in the sky when you’re starting out developing, why should you worry about how it’s going to be put somewhere, when you really don’t know where that somewhere is right away. In this scenario, here’s what the development team knew before development:
- That they would need to show management a version that wasn’t development
- That they would have to put a version into production
- That no software is perfect, bugs happen. You’re going to have to update the software.
My scenario above might seem a little weak, but it should be possible to identify these requirements from it.
This is not a small challenge to overcome though. In the big design up front world, we would still have spent more time trying to figure out the features that needed to be in there than we would have spent figuring out how to deploy. In the agile world, we don’t know what we need up front, we do the simplest possible thing and iterate over that.
In retrospect, I believe that I would tackle the choice of deployment tools, software version and work tracking as critical parts of the development. How you manage the code in the repository, how you manage dependencies on third party libraries and how you keep them in check. They all have to become part of your up-front standards.
So, development has an effect on deployment in so much as the methods chosen, the process of that development can clearly limit how you deploy. Deployment has an effect on development not so much in how you should code and what technologies you should use, but in so much as the process of development. How you check-out/commit code to your repository, how you branch, how you version or tag commits.
What’s my answer for all this? I don’t have one. Sorry.
I’m still learning a lot each day, and trying to form my opinions and solid ideas on how to achieve a smoother work-flow. I’m not certain right now whether there is too much tooling around some of these processes, or not enough transparency in the tooling that is there. Deployment into a live system is a complex task when your application is more sizable, but that doesn’t mean it shouldn’t be transparent as to what’s there, or how it’s done.
I’m going to stop this post here, and come back to it over the next few days. It’s something I’m going to spend more time considering. Hopefully getting some reasonable suggestions and ideas for others.