Before deployment, people might need to provide multiple information. For example, which nodes to deploy what services, use which tcp ports to listen on application endpoints, etc.
Even very careful person would make stupid mistakes! e.g, wrong ip format, invalid port, unsupported OS version, machine doesn’t have RAM, etc.
These human errors may not only fail your deployments, but also cause unexpected damages to your existing envs. Even mess up critical envs sometimes. So it’s better we enforce pre-check before update.
DevOps involves tons of softwares, technologies and methodologies. You finally get familiar with Nagios, but more and more people are talking about Sensor now. When you start to try OpenStack, Docker seems to be compelling. Sound familiar? It’s really hard to be on top of it!
Here are some practical tips to follow the latest DevOps trend with minimum time.
Rubocop is a static code check tool for ruby. Very handy and powerful.
Here is a list of Common Rubocop Errors, for your reference. You can simply search by your Rubocop error message in this post. And get your code improved quickly.
Like most versatile engineers, we host websites of side projects in EC2 or DigitalOcean. It might be Boostrap, php, python, nodejs, or anything charming.
We definitely want to have a quick setup, and keep routine maintenance minimum. Here are some pratical tips. Check it out!
To break silos and improve availability, DevOps/Ops should be actively collecting useful feedback of prod env maintenance on a regular basis. Enable developers to easily access it and improve feedback loop together as a team effort.
The very first and most important part. What To Examine, Providing Developers Meaningful Feedback?
Occasionally DevOps code needs to check and wait status, before running further steps. For example, wait for service A to be up, then start service B; confirm TCP port is listening, then launch requests; etc.
For simplicity or time pressure, people usually use a blind wait like “sleep 10” to fix this. This is certainly not good enough. How we can improve this with affordable cost?
After a lot of effort and communication, finally the system deployment works! To guarantee a smooth deployment anytime, we enforce daily deployment test as a next step.
Surprisingly daily deployment doesn’t always succeed like we expect, even if no major changes. More interesting, many failed tests are kinds of false negatives. So what are the obstacles? And how we can avoid them?
Lots of people are talking about CI/CD on the Internet. I wish I could learn the details what they really enforce? Quite disappointed, mostly I only see concepts, principles, and guidelines.
Yes, I know it depends on a lot of things. After supporting several projects, I DO believe there are some useful first-hand experience which are general and not that well-known. Enclosed is a Demo Jenkins.
PPT Sharing for personal understanding and judgement for DevOps