3 ms·
First, Continuous Deployment is really awesome. Second, you should completely ignore Continuous Deployment until you have sane systems. I do contract systems
by mattjaynes 13y ago
First, Continuous Deployment is really awesome.
Second, you should completely ignore Continuous Deployment until you have sane systems.
I do contract systems work for a living and have seen hundreds of live production systems. Nearly every system I see is in some kind of serious peril:
- no backups
- if backups, no docs on how to restore
- no monitoring (or very little)
- production passwords in the wild (former employees, etc)
- no configuration management
- no path to scale
- no path to replace defunkt servers
- etc... (I could go on for hours)
Often when I'm talking with a potential client, they are SUPER interested in Continuous Deployment (or whatever the hotness is at the time), but they start to yawn when I start talking about getting their core systems in order.
Your systems are the foundation of your application and your business. You wouldn't build your office building on top of an active volcano or below sea level on the coast, yet many businesses happily do this for their systems.
You know all those constant news stories about massive outages, security breaches, crippled sites, etc? I'd bet 99% of them are due to them failing at the fundamentals of sane systems. Having seen behind the curtains of so many companies, I'm honestly surprised there isn't more massive systems failure in the news.
This is a critical problem in the tech world. Does it affect you? A few of you will have amazing solid secure systems, but the vast majority of folks reading this won't.
If you're using a PaaS like Heroku or Parse, then you have most of the systems worries taken care of for you. You can breath a bit easier.
But if you are managing physical or virtual servers and aren't even using configuration management (puppet/chef/salt/ansible/etc), then your systems are probably in a very precarious situation. You might not think so, since everything just happens to be working at the moment, but you are essentially coding without using version control.
You would probably think that a developer that used email for his code version control is an idiot. You would be right. But consider that emailing code around for version control is actually better than what most companies do for their systems. Most companies set up their servers manually. They often don't even have any docs or even shell scripts.
At one client, it took them 2 weeks (!!!) to bring up a new server. The engineers thought it would take only 4 hours. Those engineers nearly killed that company.
Do you want to be a 10X or 100X systems engineer? Then use configuration management! After we put that client's systems in Puppet, we could bring up a new server in under 5 minutes. Yep, that's 4000X faster.
If you aren't using configuration management and don't know where to start, just use Ansible. It's by far the simplest and easiest to get going. I've written a quick intro to it here: http://devopsu.com/blog/ansible-vs-shell-scripts/ http://devopsu.com/blog/ansible-vs-shell-scripts/
If you're curious about how the configuration management tools compare, check out my book: http://devopsu.com/books/taste-test-puppet-chef-salt-stack-ansible.html http://devopsu.com/books/taste-test-puppet-chef-salt-stack-a...
- deleted 13y ago[deleted]
- tieTYT 13y agoIMO, the example you're using in your blog should be simplified even more. I've never heard of Passenger before and it's not something I've needed. But I have needed to ensure that a file exists in a particular folder on the server. An example of ensuring that would be more universal. Then you can explain that this vs a shell script is better because it's error prone/difficult to run the shell script twice, etc. But I did get a lot of value out of this article because now I know that Ansible exists. Thanks
- axisK 13y agoAnsible is pretty decent but new release seem to break backwards compatibility quite a lot so be prepared for playbooks not working on newer versions should you need to reuse them at a later stage. Of course virtualenv gets around this quite nicely.
- skeoh 13y ago> I could go on for hours I, for one, would love to read more of these.
- avtar 13y agoLikewise. I would also love to see some of those examples (wherever possible) being addressed using a configuration management solution like Ansible.
- createcode1 13y agoCompletely agree with Matt. You should get your house in order before aspiring to do automation or continuous deployment. I worked with one client who was trying to check off a list by trying to implement a continuous deployment on a system that he was planning to retire in a year. Bottom line is if you have system problems, fix them first, lay a good foundation and then move on to automation efforts and continuous deployment.