I'm working on something similar to what your describing, but I've not yet made a step-by-step plan.

Some thoughts,

If you need or want to change the directories for a Laravel 5 app, I wrote this for that purpose - https://github.com/TerrePorter/LaravelFrameworkLoader

You mention that you copied the staging to the production site but it was using the staging templates, did you update the .env file to point to production resources. or do you mean that it was literally pulling files out of the staging directory?

You could set up a gitlab or other internal git server and use that to move code files in to the production folder. You would need to make a list of what makes the changes that are needed to make the site act like a production site, db settings, mail settings, app/config settings, etc

Hope that helps.

Personally i have dropped Beanstalk for a while, switched to Dploy.io. This is more flexible because I am independent from the central gitrepo. Dploy.io is renamed now to Deploybot and the good thing is you are now able to build your Project before you Deploy. That can help to Cleanup the Gitrepos and makes it easier. http://www.traininginsholinganallur.in/dot-net-training-in-chennai.html | http://www.traininginsholinganallur.in/linux-training-in-chennai.html

The spammers are getting more creative it seems.

TerrePorter said:

I'm working on something similar to what your describing, but I've not yet made a step-by-step plan.

Some thoughts,

If you need or want to change the directories for a Laravel 5 app, I wrote this for that purpose - https://github.com/TerrePorter/LaravelFrameworkLoader

You mention that you copied the staging to the production site but it was using the staging templates, did you update the .env file to point to production resources. or do you mean that it was literally pulling files out of the staging directory?

You could set up a gitlab or other internal git server and use that to move code files in to the production folder. You would need to make a list of what makes the changes that are needed to make the site act like a production site, db settings, mail settings, app/config settings, etc

Hope that helps.

Hi Terre,

Thanks for your response (and for not being a spammer!). :)

I'll take a peek at your loader and see if it might be helpful.

In answer to your question about the .env file, I did change it though there's nothing in that file that seems to be path-specific. Also, I do mean that the production site is literally using the same files that are in the staging site's root directory instead of its own files. For example if I edit one of the staging site's templates or routes, that's what the production site uses. Editing the production site's files has no effect on the production site.

It seems like there's some path information somewhere in the site that I'm not able to find. Do I need to actually create a fresh app in the production site's root dir and then copy files over selectively from staging?

I do plan on setting up internal git repos to handle deployment, though I haven't done that before and finding a walkthrough that matches my needs has been a bit tricky.

Again, thanks for your help!

Still having trouble with getting these subdomains separated and I'm really baffled.

I have these two subdomains configured:

• orders.clientdomain.tld document-root: /data/www/clientdomain.tld/orders/public/
• staging.clientdomain.tld document-root: /data/www/clientdomain.tld/staging/public/

Additionally:

• Each separate document-root dir contains a complete standalone copy of the Laravel app.
• Each copy has its own .env file with APP_ENV set to production and staging, respectively
• Each copy's .env file has a distinct value for APP_KEY
• The .env file for production (orders.clientdomain.tld) also has APP_BASE_PATH=/data/www/clientdomain.tld/orders
• I have some key differences in the default view template that is served when accessing the app so that I can tell when I'm hitting orders and when I'm hitting staging
• I've also changed the namespace in the orders copy in case that was confusing things

When I go to http://orders.clientdomain.tld I get the view template for staging. I've also tried adjusting routes and any changes I make to staging are reflected at orders. Any changes I make to orders has no effect on the site that is served at http://orders.clientdomain.tld

As far as I can tell, orders is using staging's routes and views, possibly controllers too though I haven't tested those. I've searched for any files that are explicitly setting the base path, I've cleared all caches, all to no avail.

If anyone has any suggestions, I'd really appreciate it.

Before we dig into Laravel side of things, I hope you don't mind to ensure that your webserver properly maps domains to directories. Put a simple php file

<?php echo __FILE__; ?>

into each of the public directories, then visit that file across internet via both subdomains and see if it prints a different path each time.

Note: don't forget to delete that file as soon as the check is done, of course.

If that part is ok, get back here and we'll continue debugging )).

@Lewolf thanks for that input. I've done what you suggested and confirmed that the webserver is properly mapping.

Then I did the following:

• Added echo __DIR__; to the public/index.php file in both sites. Both show the correct path.
• Added echo __DIR__; to bootstrap/app.php
  • orders shows: /data/www/clientdomain.tld/staging/bootstrap
  • staging shows: /data/www/clientdomain.tld/staging/bootstrap

After doing a little digging, I thought that perhaps the various require __DIR__.'/..' lines that appear in several files were causing a path issue. I attempted changing those to require realpath(__DIR__'/..' ...) but that didn't seem to make a difference in the end.

So for some reason, the orders site is using files from the staging site's directory to serve the app.

Here's another apparent confirmation that something's going wrong in Laravel's server: if I run php artisan down in the orders directory on the server and then access the orders subdomain in a browser, the app is still running. If I do the same in the staging directory, both the orders and staging subdomains are in maintenance mode.

It seems that something's hosed in the Laravel server or artisan.

@tjmb, thanks for the extended check, you are zeroing in on the problem and this now sounds like a server filesystem problem.

Your original post didn't go into detail regarding how exactly you obtained the production copy of the files, but if you did a direct remote copy (e.g. cp -r /data/www/example.com/staging /data/www/example.com/orders) this could (in theory) cause some confusion in server filesystem, especially if symlinks were used for some directories.

A way to avoid that would be to discard your production root directory and instead re-upload all files from your local development machine to remote production app dir, like you did with staging, then run

composer dump-autoload
php artisan clear-compiled
php artisan optimize

and optionally

php artisan cache:clear

from within your production directory on the server.

However:

In your original post you mentioned you'd like a holistic git setup to deploy to both environments. If that's what you are still looking at (and doing this would certainly give you a clean start), here are very basic steps you can elaborate on.

(The following again assumes you can execute remote commands on your server via SSH).

1/ On your server, make sure you have git installed, if you don't please refer to https://git-scm.com/download/linux

2/ Then:

mkdir -p /var/git/projectnamehere.git
cd /var/git/projectnamehere.git
git init --bare

The above creates a bare remote repository on your server that you can use to hold the source code for your remote deployments. You can of course choose another location and name if you like. Just keep it consistent across all steps.

3/ On your development machine link your local git working copy with the remote git you just set up:

Go into your working copy directory, then:

git remote add prodserver ssh://user:[email protected]:port//var/git/projectnamehere.git

Of course replace your ssh connection credientials with those you use to ssh into your remote server. If you use ssh key (not password), you may have to provide the proper path to key file in /userhomedir/.ssh/config. Sorry I can't give more detailed instructions here since I don't know the OS of your local development machine. Just google "git setup remote ssh [your-os-here] with private key"

The command above will link your local working copy with the remote bare git repo you created above, and refer to it as "prodserver". You can choose another name if you like, but keep in mind if you are already using a git on your local machine that the name "origin" is probably already taken and points to your local git.

4/ Once this link is established, you can try pushing your local copy to remote repository on the server:

git push prodserver --all

(Replace "prodserver" with the name you've chosen for your git link)

If you run into problems with this step you'll have to verify and fix ssh connection problems between git and production server, sorry I can't give more detailed instructions here since I don't know the OS of your local development machine.

Note that you don't want to push the following laravel directories to your version control:

• /vendor
• /node_modules
• /storage
• .env

but Laravel already included them in .gitignore so if you didn't touch your .gitignore then these aren't probably seen by git which is good.

Instead, you'll want to create them on your remote server once in a separate location and then symlink them from inside all your deployments (somewhat similar to what you do with the database). I'll illustrate that in a moment.

5/ Once the code is pushed to remote server, you can deploy it remotely to any directory:

On your server:

cd /data/www/example.com/production 
git clone file:///var/git/projectnamehere.git .

Note the triple forward slash and the dot in the end of the last command.

The command above deploys your code to directory /data/www/example.com/production (which should be empty before that operation).

6/ Now create these (again, pick a location on the server to your liking):

mkdir /somewhere/outside/storage
mkdir /somewhere/outside/storage/logs
mkdir -p /somewhere/outside/storage/framework/views
mkdir -p /somewhere/outside/storage/framework/sessions
mkdir /somewhere/outside/vendor
mkdir /somewhere/outside/node_modules

7/ Make the directory "/somewhere/outside/storage" (and everything below) writable by the webserver user.

8/ Symlink the new directories from your deployment:

cd /data/www/example.com/production
ln -s  /somewhere/outside/storage storage
ln -s  /somewhere/outside/vendor vendor
ln -s  /somewhere/outside/node_modules node_modules

9/ Populate vendor with files (you will only have to do this once):

cd /data/www/example.com/production
composer install
php artisan optimize

Optionally (specifically, if you use gulp, elixir or other node modules) populate node_modules:

cd /data/www/example.com/production
npm install

10/ Create the .env file in the root of your new deployment by copying it from somewhere you have it, e.g. your local development or from .env.example if you still have it from the beginning of your project. Edit .env and enter the values that are specific to your new deployment.

11/ If you need to run any migrations on the database, run php artisan migrate

==========

Now, whenever you make change to your code and want to deploy, you will repeat just few simple steps from above:

• push code to your remote server (step 4)
• git pull from within the deployment directory on the server
• run these commands (or at least first three of them):

composer update
composer dump-autoload
php artisan optimize
php artisan migrate

==========

When you need another copy of your app, you repeat steps 5/, 8/, 10/ and 11/ for each new deployment.

==========

When you need to rollback your application to a previous state, google for "git revert to specific commit" there are plenty of ways.

Although this cannot be called a "tutorial" and it hardly scratches the surface of what can be done to achieve a really smooth deployment process, hopefully this will at least point you in the right direction and you'll be able to google the rest of things.

@Lewolf, thank you very much for taking the time to write those excellent instructions! They were very helpful in giving me what I needed for setting up deployment through git.

I followed your instructions and now have two copies of the app set up on the server, each cloned from an individual git repo. However, I'm still seeing the same issue with orders.example.com using the views and .env settings from staging.example.com

Here's how I now have things set up:

Production Site

• /home/myuser/app-orders contains the node_modules, storage, and vendor dirs for this copy
• /data/www/example.com/orders contains files cloned from the production git repo, with symlinks to the above locations

Staging Site

• /home/myuser/app-staging contains the node_modules, storage, and vendor dirs for this copy
• /data/www/example.com/staging contains files cloned from the staging git repo, with symlinks to the above locations

I repeated step 9/ of your instructions for each of these, figuring that a separate composer install might be necessary to keep them truly separate.

Any thoughts on where to go from here would be most welcome.

@tjmb, ok let's continue where we left it then (if you haven't found a solution yet, of course).

You said that __DIR__ in public/index.php gives you the correct path for either deployment, but __DIR__ in /bootstrap/app.php reveals that in both cases, app.php is pulled from /data/www/example.com/staging/bootstrap.

Here's the order used by Laravel to load files at start:

__DIR__.'/../bootstrap/autoload.php';

// here's where Laravel framework loads and application initializes:

=> __DIR__.'/../vendor/autoload.php'; 

// (if exists) Laravel framework loads its optimized class loader generated by php artisan optimize, which can be cleared by php artisan clear-compiled:

=> __DIR__.'/cache/compiled.php'; 

And finally

require_once __DIR__.'/../bootstrap/app.php';

If you are using a debugger of some kind, you might want to step through this code watching the value of DIR on each step and especially, setting a breakpoint on line 3 in index.php:

require_once __DIR__.'/../bootstrap/app.php';

and stepping into that and ensuring it steps into the correct file. If no debugger is available and you don't want to bother setting one up, just

echo __DIR__.'/../bootstrap/app.php';
echo '<br />';
echo realpath(__DIR__.'/../bootstrap/app.php');

before that line in index.php and see what happens. It is expected to translate to /data/www/example.com/orders in the end

Some other points that I would check are:

• If there's some file in the application where paths were once hardcoded, and this file is committed to Git (and thus deployed to any location screwing things up). Search your working copy for the word "staging" or whatever your deployment directory name is. This may as well be in some cached/compiled file (not part of regular clean Laravel installation) that just needs to be removed from Git.

• Check your include_path setting on the server, preferably by

echo ini_get('include_path');

the problem might lie there (although I can't quickly imagine how exactly that could circumvent __DIR__).

• Finally, try cleaning up all files from /bootstrap/cache. That's what php artisan clear-compiled should do, and if you ran composer install or composer update, pretty good chance it already did that, because it is set up as pre-install and pre-update script in composer.json, but - just in case. (Note: if it helps, you should probably think of removing that folder from Git altogether, or at least stop tracking its descendants).

HOSTING LARAVEL 5.4 PHP 7 Shared Hosting It offers web hosting for your projects in Laravel Framework all versions (4.x up to 5.4), we have support for PHP versions 5.3, 5.4, 5.5, 5.6, 7.0 and 7.1, up to 20 times faster thanks to the storage technology SSD. Http://hostinglaravel.com/

Why not use Envoyer to deploy your Laravel app to staging? It is pretty easy to use: https://www.cloudways.com/blog/php-laravel-envoyer-deployment/ Once you have deployed PHP app, you could check the status of your application from three locations (New York, London, Singapore). In case of a disaster, you have the option of rolling back the current deployment. You can enable this option by providing the health check URL in the settings.

Additionally you can set up heartbeats to monitor cron jobs for your application. You could also set up a notification channel like Slack and Hipchat to receive notifications.