Answers: <p>The best practice is to <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#staging-vs-production" rel="nofollow noreferrer">separate production and staging(testing) inventory</a>.  See <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#staging-vs-production" rel="nofollow noreferrer">Staging vs Production</a>.</p>
  
  <blockquote>
    <p>This way you pick with -i what you are targeting.</p>
  </blockquote>
  
  <p>To make it more robust you might want to clone a separate structure for production and restrict access to it. Pull from staging before deploying to production.</p>
  
  <p>In detail, this would mean to 1) put the <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#directory-layout" rel="nofollow noreferrer">directories</a> into git, 2) make sure staging is committed, pushed and merged, and 3) then pull to the production and deploy. The <a href="https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows" rel="nofollow noreferrer">workflow</a> is up to you.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-05-10T12:25:13.233Z
Answers: I targeted dev, but some of the machines in dev inventory had prod IPs. I think there was reshuffling by the infra team a while back and the branch i was on used that. I am looking for a fool proof ,solution that will exclude such possibility.
Answers: JavaHead
Answers: CC BY-SA 4.0
Answers: 2019-05-10T12:31:24.553Z
Answers: Sure, I've updated the answer. Please, update the question (you're able to edit it)  and delete the comment to make the thread clear.
Answers: Vladimir Botka
Answers: CC BY-SA 4.0
Answers: 2019-05-10T12:19:56.173Z
Answers: 2019-05-10T12:42:42.607Z
Answers: 2019-05-10T12:42:42.607Z
Answers: Vladimir Botka
Body: <p>Last night I ran a playbook from a wrong branch that referenced an old inventory file with old IPs for each server, and deployed a dev build to a production machine. What would be a a good practice to avoid such mistake from happening in the future? How can I isolate environments better?</p>
  
Tags: <ansible><environments>
Title: Preventing accidental production deployments in ansible
UserDisplayName: JavaHead
ThreadText: # Preventing accidental production deployments in ansible
  
  (Asked by: username_0 on 2019-05-10)
  
  Last night I ran a playbook from a wrong branch that referenced an old inventory file with old IPs for each server, and deployed a dev build to a production machine. What would be a a good practice to avoid such mistake from happening in the future? How can I isolate environments better?
  
  **Tags:** ansible, environments
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-05-10. Score: 1 | Accepted answer
  
  The best practice is to [separate production and staging(testing) inventory](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#staging-vs-production). See [Staging vs Production](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#staging-vs-production).
  
  > This way you pick with -i what you are targeting.
  
  To make it more robust you might want to clone a separate structure for production and restrict access to it. Pull from staging before deploying to production.
  
  In detail, this would mean to 1) put the [directories](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#directory-layout) into git, 2) make sure staging is committed, pushed and merged, and 3) then pull to the production and deploy. The [workflow](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows) is up to you.
  
  > **Comments:**
  > **username_0**: I targeted dev, but some of the machines in dev inventory had prod IPs. I think there was reshuffling by the infra team a while back and the branch i was on used that. I am looking for a fool proof ,solution that will exclude such possibility.  
  > **username_1**: Sure, I've updated the answer. Please, update the question (you're able to edit it)  and delete the comment to make the thread clear.  
  
  ---
  
  