What's the best practice to have both staging and production environment

[davedriesmans]

My idea is that the artisan commands sets the configuration for a certain bucket, project and database.

How can we work with the package if you want to have both a staging and production environment in google cloud?

[shpasser]

Please describe a sample workflow, will continue to work on that...

[shpasser]

It is very important to analyze the things before we implement anything.

[davedriesmans]

The flow in mind now is this:

• two different projects on google cloud : project and project-staging
• create three different laravel folders locally, with artisan gae:setup for the staging and production env and files --> /project-local, /project-staging/, /project-production
• to deploy: first do a git pull for the correct branch and then gcloud app deploy from the correct local directory. (the env file will be copied but ignored with git, probably have to do the same for the yaml)

what do you think?

[shpasser]

What would be the difference between staging and production configurations?

[skipatrol]

I'm interested in this topic to see if something can be done with artisan. For me the things that are different between dev/test/prod apps typically include header files, bucket names, db names, etc... and then the usual development activities of adding views and models, etc.

My process right now is to create 3 GAE projects and have 3 separate repositories in source control for the dev/test/prod environments. We start with a working Laravel app as a base in all 3 repositories and my team forks off of the dev repo for development work (each creating his or her own GAE project for personal dev app), merging back into the master branch when functionality is ready for peer review and testing. When I need to move dev work into the test env I use a diff/merge tool (WinMerge in this case) to compare the installs and copy new/changed files into the test app, which is then deployed. The merge tool allows me to skip over the files that are supposed to be different between applications and allow them to remain different.

The idea of being able to deploy from a single code base is appealing. I think you'd need to identify all the things that are different between environments and then have configuration files to be used by the artisan command, which could then ensure all settings are correct for the environment you're trying to publish to and maybe even execute the gcloud app deploy to the right app at the end of the artisan script.

[davedriesmans]

What would be the difference between staging and production configurations?

Different git branch, project, database and db host

[shpasser]

1. I cannot see how GIT branch affects the workflow of GaeSupportL5.
2. Very soon project is not going to be extracted from app.yaml, because it is deprecated.
3. Database name and DB host - is a single line in .env file that has to be edited once.
4. gcloud app deploy command expects to have all of the files in a single tree.

As far as I see you would like to have another level of automation above gae:setup. Meaning maybe another artisan command, which will call gae:setup. Will have to define parameters and behavior for that new command.