Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Configuration and environments", configs of team members #120

Closed
PowerGamer1 opened this issue Feb 8, 2016 · 21 comments
Closed

"Configuration and environments", configs of team members #120

PowerGamer1 opened this issue Feb 8, 2016 · 21 comments
Labels
type:docs Documentation
Milestone

Comments

@PowerGamer1
Copy link
Contributor

"Configuration and environments" doc states that yii2-app-advanced template somehow solves the problem of different team members having different -local.php configs under dev environment. But all -local.php configs go under environments/dev folder which is commited in its entirety (since there are no .gitignore files for environments folder or inside it). So it is unclear where does each team member keep his copies of -local.php configs and how and when (before or after or during php yii init) that team member's copies of -local.php configs are copied into final project folders.

@samdark
Copy link
Member

samdark commented Feb 8, 2016

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
Copy link
Contributor Author

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
Copy link
Member

samdark commented Feb 8, 2016

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
Copy link
Contributor

CyberPunkCodes commented Jun 20, 2016

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
Copy link
Member

samdark commented Jun 20, 2016

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

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

@CyberPunkCodes
Copy link
Contributor

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
Copy link
Member

samdark commented Jun 20, 2016

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.

@samdark samdark added the type:docs Documentation label Jul 25, 2016
@samdark samdark added this to the 2.0.13 milestone Apr 26, 2017
@krukru
Copy link

krukru commented May 15, 2017

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
Copy link
Member

samdark commented May 15, 2017

Add it to normal config file within environments.

@krukru
Copy link

krukru commented May 16, 2017

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
Copy link
Member

samdark commented May 16, 2017

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

@krukru
Copy link

krukru commented May 16, 2017

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
Copy link
Member

samdark commented May 16, 2017

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
Copy link

krukru commented May 16, 2017

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
Copy link
Member

samdark commented May 16, 2017

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

@PowerGamer1
Copy link
Contributor Author

@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
Copy link

krukru commented May 16, 2017

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

@armpogart
Copy link

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
Copy link

andrewpros commented Aug 13, 2017

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 samdark closed this as completed Nov 2, 2017
@samdark
Copy link
Member

samdark commented Nov 2, 2017

Solved by 7cfbb6d

@sheillendra
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:docs Documentation
Projects
None yet
Development

No branches or pull requests

7 participants