# Extending Trellis to four environments

**URL:** https://discourse.roots.io/t/extending-trellis-to-four-environments/14306
**Category:** trellis
**Created:** 2018-12-09T05:41:22Z
**Posts:** 6

## Post 1 by @gilad — 2018-12-09T05:41:22Z

What is the correct process for adding a fourth environment to our Trellis setup?

The goal is to have the following:

1. Development
2. **QA/RC** (this is the new step, of course)
3. Staging
4. Production

The new **QA/RC** environment is remote, but should include dev-specific requirements (like `require-dev` from `composer`).

---

## Post 2 by @knowler — 2018-12-09T07:46:35Z

I started drafting this repsonse on my dev machine but had to switch to my phone so I couldn’t test the result. I figured I’d share this to at least point you in a good direction. Perhaps someone could swoop in and confirm this correct.

For **provisioning** your new environment, the server setup will be the same as the other two remotes (stating and production). The procedure needs to be different for the application **deploy**. Here are the full steps of what you need to do:

1. Duplicate and rename the files or directories for either of remote environments within [`group_vars`](https://github.com/roots/trellis/tree/master/group_vars) and [`hosts`](https://github.com/roots/trellis/tree/master/hosts), then fill in the relevant information for your new environment.
2. Make a copy of `trellis/roles/deploy/hooks/build-after.yml` in `trellis/deploy-hooks`.
3. For your new copy of the `build-after` hook, you will need to modify the final task — “Install Composer dependencies” — to reflect the following change:

```
- name: Install Composer dependencies
   composer:
+ no_dev: {{ 'no' if env is 'qa' else 'yes' }}
     no_scripts: yes
     working_dir: "{{ deploy_helper.new_release_path }}"
```

That assumes you’re new environment is called `qa` but feel free to change it to whatever you’d like.

---

## Post 3 by @gilad — 2018-12-09T20:26:12Z

Thank you so much!

I’m a little lost on steps 2 and 3:

- The paths you specified are a little different from what I’m seeing, and…
- I’m a little confused about whether step 3 applies to the `build-after.yml` that’s already in place, or to a copy I should be making in step 2.

Thanks again for your detailed support!

---

## Post 4 by @knowler — 2018-12-09T20:43:00Z

Oops. I made a typo in the path for step 2. I’ll update my original post so it’s more clear. For step 3 you would need to modify the copy — I’ll clarify that in my original post as well.

---

## Post 5 by @gilad — 2018-12-11T02:49:46Z

Thanks again for the detail. I should be able to try this out later this week.

Meanwhile, could you point me in the right direction for additional information about what’s happening here under the hood? Some sort of gentle intro for ansible/etc noobs perhaps?

(Not too gentle, though… I do need to get to building my own configs sooner rather than later…)

---

## Post 6 by @knowler — 2018-12-11T03:18:44Z

> [@gilad](#):
>
> Meanwhile, could you point me in the right direction for additional information about what’s happening here under the hood? Some sort of gentle intro for ansible/etc noobs perhaps?

I don’t know of any resources off hand. From my own experience Ansible is decently easy to learn from just reading the config files. They’re all in Yaml so it’s readable by design. Just start at the top level with one of the playbooks (i.e. `server.yml`, `dev.yml`, `deploy.yml`, or `rollback.yml`) then dive into the plays/roles that they have. The `deploy` role is probably a great one to get started with. It includes some hooks — which is what we’re using above.

---

## Post 7 by @system — 2019-01-20T05:41:22Z

This topic was automatically closed after 42 days. New replies are no longer allowed.