A new developer joins your team on Monday. They need SSH access to three servers, permission to deploy to staging, read-only access to production logs, and sudo for a handful of commands. Do you give them full root access and hope for the best? Absolutely not. Here's how to do it right.
151 posts tagged with "DevOps"
DevOps practices, CI/CD, and automation
View All TagsYou rename a tag in your Terraform config, expecting a simple metadata update. Instead, Terraform announces it will destroy and recreate your production database. Your heart rate spikes. Understanding how Terraform decides to create, update, or destroy resources — and how to control that behavior — is the difference between a calm deploy and a production incident.
You just pushed code to GitHub. Wouldn't it be great if tests ran automatically, a Docker image got built, and the app deployed itself — all without you touching a single server? That is exactly what GitHub Actions does, and you can set it up faster than you think.
You just got a new job. Half the servers run Ubuntu, the other half run CentOS. Your Ansible playbooks need to work on both. Your Dockerfiles target different base images. Which package manager do you use? What are the actual differences? Let's clear this up once and for all.
Terraform by itself does not know how to create an EC2 instance, a Kubernetes pod, or a DNS record. It delegates that work to providers — plugins that translate your HCL into API calls. Understanding providers is understanding how Terraform actually talks to the outside world.
It is 4 PM on Friday. Your team has six feature branches, two of them have been open for three weeks, and someone just force-pushed to develop. The merge conflicts are so deep you are considering a career change. This is what happens when you pick the wrong Git workflow.
