Deployment can be approached in many ways - most of them are valid and good. It’s not a purely technical problem. Instead, it’s highly subjective and depends on your preferences, your team and your project. A solution which is perfect for one person, could be a very bad fit for you, and vice-versa.
The biggest confusion, when it comes to choosing a deployment method, is caused by having the wrong focus (too narrow or too technical), and a lack of general knowledge. You can put yourself in a better position to find the right deployment method for yourself if you make sure that you equip yourself with the right kind of knowledge beforehand.
First, you need to get a general understanding of deployment. Then you should take a very good look at your own skills, goals and needs.
Asking yourself questions, and trying to answer them is the best way to get started and find out what’s missing from your current overview.
Do you know the basics?
You won’t be able to compare deployment approaches, if you don’t know what you’re dealing with. Here are a few angles you can try, to check whether your knowledge of deployment basics needs some work:
- Do you know what production means?
- Have you looked into why runserver isn’t your production server?
- Do you know how a web server and an application server work together?
- Have you heard about WSGI?
In addition to those - take a look at the 12 factor app manifesto. It’s a great thing to read if you want to know more about modern web apps and best practices around architecture choices.
Have any more questions? DM or @ me on Twitter.
Figuring out your deployment context
Before diving into technical details and considering tools, it’s a good thing to figure out your personal needs and goals.
What’s the simplest way to get most of what you need right?
Simplest, not “the best”. You have a few options in mind already, but what’s the most barebones way to get things done? What would get the job done for you?
Really try to answer this, before looking for a way to tick all of the boxes you can imagine. Think about what might be just barely enough to get you going. What requirements can you skip out on, and still have things work out well enough?
What problems do you really have right now?
What’s bothering you at the moment? Which of those are really costly showstoppers? Be sure to distinguish between actual problems, and “wishlist entries”.
What goals can you achieve once those problems are gone?
Fixing your deployment issues, should enable you to get more things done.
Don’t aim for something like “the problem is fixed” - instead, think of “superpowers” you’re giving yourself or your team. “Being able to focus on shipping features instead of wasting hours on tedious deployment tasks” is a nice goal to aim for.
How would a workflow without your current problems look?
Before diving into tech, you can imagine how your ideal deployment workflow might look like. Try not to think in tools, but in reproducible processes. “I can roll back to a past version”, “I can deploy a new version without getting nervous”.
How would you like to interact with your ideal deployment? What changes can you see coming in the future? If you want some inspiration, check out this post.
Questions to evaluate your options
Alright, you should have a clearer picture of your goals and problems by now. Notice how none of those had to do with any kind of tooling in particular? Good!
If you don’t know how to deploy - go with Heroku. It’s pretty darn solid.
If you are torn between multiple technologies and approaches - go through the following questions and try to “rate” each approach regarding each question. “Is this the best way” is a really hard question to answer. Looking at your options from different angles will be way easier.
Which problems are solved by (THE APPROACH YOU’RE EVALUATING)?
You know what you need. Will this approach help you? If something does things which don’t solve a problem you’re having, chances are it’s designed for someone in a different situation than you are in right now.
What parts of this approach seem like overkill?
If your solution is too simplistic, it will get in your way. If it’s too fancy, you will bump into issues you wouldn’t have otherwise. What details make you go “huh, why’s that”?
What new, interesting problems might arise due to this approach?
Everything has a price. For example: if the thing you’re evaluating is using Docker, but you haven’t worked with Docker before - chances are that you’ll run into some Docker problems eventually. What complexity are you introducing with this approach? What can go wrong with it?
Is it a good fit for you and your team?
When it comes to ops, you want to understand the things you’re going to rely on. Which parts of this approach are familiar to you? Which ones are completely new? Are you using familiar technology in ways which you know well? Is there an alternative which is closer to your comfort zone?
What are the parts that you’d be responsible for?
Each moving part in your system, is something which needs attention to keep running in the longterm. If you’re using a PaaS like Heroku, the fine people who work there will keep the platform running for you. You’ll only need to make sure your application is configured correctly. If you go with a bare-metal server and run 4 different services on it, you’ll need to take care of all of those yourself. Is this something you need, or is it a distraction?
In conclusion
Finding the “best” deployment approach can be a tough task. There’s no single answer which would suit everybody. You have to figure out what’s a good fit for you yourself.
It’s way easier to think about your needs first, and then see which of your options would help you satisfy most of them. I hope the questions provided above will help you gain some clarity while you approach the problem from different angles and looking at smaller parts of it.
If you have figured out an approach which looks good enough - just go for it! It’s not something which needs to be perfect from the get-go. Just make sure to be diligent about basic security aspects and somewhat adhere to basic best practices. You’ll be find.
You can always make incremental improvements later on, and fix things. If in doubt, go with the simplest approach, and make it work. Happy deploying! I hope you will be able to make it work and can continue working on stuff that matters sooner than later.