Deployment approaches

i believe most use git and composer. and if your hosting provider does not support it, then perhaps it is time to change the provider.

My workflow is to git clone my Github repo and then configure nginx.

I manually run git pulls and composer updates, but I guess you could use git hooks to improve the flow, I never got around to it. I think if I ever need something more complex than what I have right now I'll just buy Forge.

@keevitaja e @ruigomes, thanks for response! ;)

I use Git here and my projects are in a central repository. But my question is: a simple git clone is enough to deploy an application to a server?

I think there are many tasks that should be considered in a deployment process like:

1. Prepare assets for production like compile, concatenate and minify CSS and JS, optimize images and copy all to public folder (I use Grunt for that)
2. Copy the current release to /var/www/html/myapp folder
3. Adjust some permissions like add apache user as owner of myapp directory and give some permissions to storage directory
4. Clean some files that should not be in production but should be in version control (like Gruntfile.js, bower.json, composer.json and phpunit.xml for example)
5. Run composer to install dependencies
6. Run database migrations
7. Clean and warm up cache
8. Pointing symlink correctly to the new release

How can I deal with these tasks in the deployment process? Should I version my generated assets to get an easier deployment process? Is it a good a practice? Should I install my dependencies in production or just copy it from another machine?

Thanks ;)

My most complex deployment process is still simple enough that I can manage it through a short shell script. Said script does the following:

1. Put the app in maintenance mode
2. Pull the latest changes from master
3. Migrate the database
4. If it's not on production, run the full suite of tests (includes re-seeding the DB with test data, which is why it doesn't run on production)
5. Clear the application cache
6. Dump autoload
7. Bring the app out of maintenance mode

It's still only about 40 lines though, so consider it fairly simple.

I think this new lesson shows very good, how to deploy with forge and github.

Hi @ax3lst, thanks for reply!

My situation is little different from this screencast. My code is in a Git server inside my network at my job not in GitHub and I should deploy it to another server here.

Hi @thepsion5, how do you deal with assets? Do you use Grunt/Gulp?

[]s

@marcelgsantos Currently, our frontend is simple enough that I don't really have to deal with assets.

For information I am the developer of Rocketeer, we use it to deploy all our applications and although it's agnostic (it can deploy Rails app, static apps etc) it has nice additions for Laravel apps. You can create complex deployment procedures with it, if any of you want to give it a shot, I'm always happy to help.

We use gitflow, so we map develop branch to the develop environment, release branch to q&a environment, and master branch to production & sandbox. Then, we us Jenkins to deploy a zip of the artifacts from our code for projects in the following manner...

upon commit to the branches above, all of the test are ran, and then upon success, we do one of 2 things depending on if the project is on AWS or not...

• AWS - we build an entirely new "server" using packer, deploy the code to the new server, and then save the sever with the application as an AMI. We then deploy the new AMI as a server behind the load balancer, and turn of old server. There is a little more complexity to this with migrations, put we have built an artisan command that runs migrate on the sever boot, but it checks for a database flag to see if any other server is booting, which is already running the migration.

• Standard server (physical or virtual) - we create a new folder in /var/www/ as the build number, copy zip built from jenkins into new folder, put the application into maintenance mode, run migrations from new folder, move the symbolic link to new folder.

Hi @Anahkiasen, I'm glad you're here and I was just looking for someone to help me with Rocketeer! I'm glad you're in Laracast as well :)

My case is very similar to @marcelgsantos (BTW, have you found a solution? :) and I've never used Capistrano so I'm kind of confused.

I have a small team of developers and we'll start working with Laravel 5 in a new project. I'm using GitLab for now to maintain my remote repos (I'm looking at gogs too, a very nice and clean solution writen in Go, if you guys want to check it out, http://gogs.io/), and we're following the git branch model (master for production, dev for dev, so on and so forth) to organize our deployment. Each developer has a Vagrant VM that is based in the development server and not every developer should be able to deploy to production, only the project leader.

Can I use Rocketeer in this case?

You absolutely can: you'll configure Rocketeer to clone from your private repository, you can use contextual configuration to set which server receives which branch, etc. For the Vagrant VM it might be trickier unless you use some kind of key forwarding as you'll need to be able to ssh into the server from the VM if that's where you want to deploy. There are no roles restriction in Rocketeer though, as long as someone is able to ssh into the connection they can deploy to it.

Thanks for the reply @Anahkiasen

I'll take a better look at Rocketeer then :) Where should I install it? Should I place in the same server as GitLab or in the production server? I don't exactly know where to put Rocketeer and how to execute its tasks after a push to the remote repo.

Time for Mr. Way to make a video about deployment best practices xD

+1 for Rocketeer, it's awesome. You install it on your local machine with composer.. the rocketeer docs go over setting it up, follow those.

@itstrueimryan Agreed :) He already did but using Forge, not a private solution. A video like that would help but I think it's out of Laravel's scope, since there are many options when we talk about deployment, in general. It really depends on your needs.

@austenc I can't install it locally, since not every developer in the team should be able to deploy to production. For one person to maintain an app, it's ok to follow this approach, but in my case, I need something that can deploy only after a pull request to the remote repo (GitLab) has been accepted.

Maybe if I put Rocketeer in the same server as GitLab, I can trigger a WebHook to execute the tasks after the repo has been updated.

Oh boy... hahah

@vvinhas -- why not .gitignore the .rocketeer directory, and then just set it up local only to the machine you'd like to deploy from?

You don't even have to add the dependency to the project, just composer global require anahkiasen/rocketeer and you're good to go.

@austenc @Anahkiasen

I can't have it installed in my Vagrant VM, I need everything to be automatic. Let me explain :)

Let's assume we have 3 projects and 1 team of developers. The remote repos for each project are hosted on the GitLab server. Each project has a project leader, that basically is one of the developers in the team. The project leader must accept the pull requests before it goes to production and for that we use GitLab, that works pretty much like a private GitHub. All right, that's the scenario!

What I'm trying to achieve is this. Everytime the project leader accept a pull request to the master branch, a hook must activate Rocketeer and automatically execute the deploy tasks to put it live in the production server. Similar to Heroku (I guess, because I've never used it)

That's why the "power" to deploy can't be in the human hands lol, it's supposed to follow this process and let the project repo automatically deploy the app and do whatever it needs to go live, like migrations, seeding, etc

@vvinhas, You need for "automatic" is exactly why we use Jenkins--it is the "extra" team member for us that does the steps that always needs to be done when one of the developers pushes code into the repository.

We use the enterprise version of GitLab (gives us the hook into Jenkins to display build status on a merge request) and have a commit hook on that "tells" Jenkins that new code is there to do something automated on it. Upon commit, Jenkins then pulls the latest copy of the code from GitLab, and does all sorts of automated steps from running code sniffer on it to make sure that the code matches PSR's to running the automated test to building a zip with all of the composer packages and assets compiled to deploying the code. The steps that it does are dependent on the branch that got committed to.

• feature/* just runs code sniffer & automated test
• development does feature/* steps + build zip of code to get deployed to development server
• release/* does like development, but puts code on Q&A server
• hotfix/* just like feature/*
• master does like development, but puts code on production & sandbox

I would guess that one of the steps could be rocketeer if that is the way that you need/want to deploy, but you are going to need something like Jenkins to "glue" it all together for your team. There are other Continuous Integration applications out there, but we have found Jenkins to be the most flexible.

Thanks for your answer @jimmy.puckett that's exactly what I need.

I was trying to avoid using a CI server, since for now we don't run automated tests and check the code for standards, however, I think that I won't be able to run from it. At least I will have everything prepared for the moment that we start to run our tests and deploy.

I looked at Jenkins, GitLab CI, Travis and others, but since the solution must be free, I think Jenkins is the way to go.

Anyway, thanks a lot Jimmy! I'll come back if I need help (and I probably will haha)

@Anahkiasen what's happening with Rocketeer nowadays? Only a handful of commits in a longer period of time. Is it dying?

I haven't found the faith to get back to it, I stuck myself in a corner with Rocketeer 3 by seeing too big and now there's so much that needs to be done to get it to a stable release. I'd need some collaborators to lend a hand but it's hard to find people willing to get into a codebase like that, if anybody here is motivated, ping me on the Gitter chat, if I could get it back on track at least I could take it from there.