"Configuration and environments", configs of team members

[yiisoft]

"Configuration and environments", configs of team members

[samdark]

Yes, this part could be elaborated. env is a source for init which is usually done once and contains common template. Then -local.php files are edited directly.

[PowerGamer1]

env is a source for init which is usually done once and contains common template.

Is the environments folder supposed to be commited into respository in its entirety or partially or not at all?

Lets say there are 10 team members. Lets say everyone of them uses their own version of main-local.php for dev environment. Whos (if anyone) version of main-local.php should be put under environments/dev folder?

Now lets say 5 out of 10 team members use one main-local.php for dev environment and the other 5 members use another version of main-local.php. Whos (if anyone) version of main-local.php should be put under environments/dev folder?

Then -local.php files are edited directly.

So basically you as a team member must store somewhere separately your own environments\dev folder with all the customized -local.php configs and then manually copy it over into the project folder after first doing php yii init. Is that correct?

[samdark]

Is the environments folder supposed to be commited into respository in its entirety or partially or not at all?
Yes, it's supposed to be committed.

Lets say there are 10 team members. Lets say everyone of them uses their own version of main-local.php for dev environment. Whos (if anyone) version of main-local.php should be put under environments/dev folder?

Noone's. A common template for development should be there.

So basically you as a team member must store somewhere separately your own environments\dev folder with all the customized -local.php configs and then manually copy it over into the project folder after first doing php yii init. Is that correct?

Usually it's doing init then adjusting DB connection, cache etc. manually. There aren't that many environment specific things usually so no need to keep these somewhere else. init is done at the very start of development and then these local configs are rarely overridden.

[CyberPunkCodes]

This is how I use environments:

I usually have my test site on OpenShift or some other cloud host. This is so I can show it to the client without risking anything.

On a fresh Yii2 Advanced install, I go straight to the environments directory. I put in my local db info into the "dev" directory. I put my OpenShift db config variables in the "prod" directory. I then run init into development mode. Actually, I made a Yii2 repo with the OpenShift DB variables already in it :)

When you init into development mode, it copies the dev folder (actually it's contents) from the environments directory into the application for use. Quite nicely I must say. Notice, these files moved from the environments dir, are not committed to git. They are for your personal use only.

When I push to OpenShift, I have it init into production mode. Which copies the environments "prod" files live into the site for use. Thus, it knows how to use my OpenShift server (db).

Say you have a co-worker on the project too. In the environments directory, where you have dev and prod folders, you would make one for him. Maybe named steve.. So now your environments looks like this:

- environments
    + dev
    + prod
    + steve

When Steve runs init, it will copy his own directory live into the site. This is so he doesn't have to waste time setting up his db and other settings every single time.

You could use dev as a test server (OpenShift in my case). Then production would be a final server (say Amazon). Then you could make a directory for everyone working on the projection, including you

- environments
    + dev
    + prod
    + steve
    + joe
    + frank

When the project is done, you push it to Amazon.

[samdark]

I put my OpenShift db config variables in the "prod" directory.

It's not advised to store production credentials in the repository.

[CyberPunkCodes]

Your right, and I don't. I should have been clearer. They are environment variables, not the actual credentials. And the repos aren't public on github anyways.

In my case, I have hooks set so when I get push, it automatically runs composer and init on the server. With cloud hosts like OpenShift and Heroku, it's a pain to do much on the server end just to run init. So those credentials need to be in the repo so they are pushed. They are usually env vars like:

getenv('MYSQL_DBNAME')

[samdark]

Ah. OK. That makes sense for your environment. env vars are good in case you're running a single project per server or container. If not, it's better to stick to files.

[krukru]

So this exact issue has been puzzling me and my team and we were wondering what would be considered a best practice approach with the current environment system as it is.

The use case is:
A team of N developers are working on a project. They all clone the repo and init the dev environment.
They each tweak their -local.php config to match their needs. After some time, it is required that we add a new entry to the config (lets say we add a new component), but the change should only be applied to the dev environment, production should not know of this component.

How should this new config change be distributed among the team members? If I add the new component to main-local.php under dev/environments folder, then when the developers reinit the project they will lose their personal config. If I add it to a normal config file, then it will be visible on all environments, which I want to avoid.

I would like to hear your thoughts on how you solved this issue.

[samdark]

Add it to normal config file within environments.

[krukru]

Wouldn't that require the developers (which have already cloned the project) to run the init script again? This will cause them to lose their local changes made in the -local.php files.

[samdark]

Yes. That would require to run ./init again but won't require them to override local configs when asked.

[krukru]

Can you please explain? How would the changes in environments/dev/common/config/main-local.php end up in common/config/main-local.php if you choose not to override the existing file?

[samdark]

As I said, you won't change environments/dev/common/config/main-local.php, you'll change another config file which isn't directly modified by developer.

[krukru]

Thank you for your help. What we ended up doing (if anyone reading this is having the same issue) is adding two new configs, environments/dev/common/config/main-dev.php and environments/prod/common/config/main-prod.php. There files are added to git and this is where we will keep environment-specific configurations that need to be shared among the development team.

[samdark]

Yes. That's what I'd do as well.

[PowerGamer1]

@krukru

and environments/dev/common/config/main-prod.php.

Did you mean environments/prod/common/config/main-prod.php (second directory prod instead of dev)?

[krukru]

@PowerGamer1 right, I meant prod :)
Updated, thanks

[armpogart]

What about switching to .env file in template and keeping environments only for environment specific global configs. I mean it's really easier to work with .env file in team and adding it to .gitignore.
That is the way we have modified the default template and are using it in production over the year (both in normal environment and docker/kubernetes/openshift environments).
And for loading .env we're using phpdotenv to both load from the file and actual environment variables.
If the team will agree, I can prepare PR based on our own template implementation and keeping environments folder there too, so it won't even be mandatory to use on or another.

[andrewpros]

Then what is the recommended way to deploy production config in case of update? Production should have its own *-local files right? And it is also not recommended to keep production config in any vcs, so the config shouldn't be in main config files, shouldn't be also in local dev files, production config should be on production local files only?
Because right now, with that structure, its really tempting to put production data in main config and override it in local dev with dev db etc. and have empty local on production.
Why, cuz if the team is small or especially for one dev it is just simple, code repository is private anyway.
Any input on this?

[samdark]

Solved by 7cfbb6d

[sheillendra]

For this case, I think Yii2 should implement .env as Laravel did.