Development Server to Production Server, Versioning, etc.

https://www.youtube.com/watch?v=5Y4STYfvpk4&list=PLwAKR305CRO_WMJAJxGz6UCViQyAjdjgo

Version Control:

https://laracasts.com/series/git-me-some-version-control

I think the easiest solution for someone in your boat is to use Laravel's Forge service combined with Digital Ocean (or AWS or Linode). You can also use automatic deployments, which makes updating your code...automatic.

So Forge will create a Digital Ocean server for you (or whichever cloud service you use), all set up with everything Laravel needs, plus configures the server. This is your own server that you aren't sharing with anyone else, so you aren't limited with what you want to do with it like you would be on shared hosting.

You would set up your project on github (or bitbucket or gitlabs). You can get a cheap plan that allows for private repositories so no one else would be able to access your code.

I tend to have 2 major git branches: master and development. The master branch is my "production code". I set up forge to watch that master branch for changes. The development branch is where I do code changes and test locally on my dev computer. When everything is working on the development branch (let's say I'm adding a new feature), I merge it into the master branch, which Forge detects and automatically deploys the master branch to the production server automatically.

So you'd be using git on your local machine. You commit your code changes to github. When github detects code changes, it will automatically push them to your server, run migrations and everything else. It's seamless. You make code changes, push them to github and your code gets automatically deployed to your server. Pretty slick.

Yes there are a lot of services that can do this, but this is a great and simple setup if you are new to all of this stuff. It sounds complicated, but it's pretty easy. You can also have multiple websites on the same server. Each one would have it's own git repository.

Here is a good laracasts series that shows how easy this is: https://laracasts.com/series/server-management-with-forge

Do you use git currently?

@Cronix , First, THANKS for the great explanation! I have a git account but I have never used it. I'm at the "developing local only" stage. Everything you say makes sense, and yes, I probably need some idiot-proofing at this point so that everything "just works". I think I will go that route. The only other question I have is about versioning locally with git, or does git not handle versioning. I want to be able to roll back if I have any issues/bugs that I missed during testing that I can't quickly/easily fix. I understand all of these concepts fairly well. I've just never put them into practice myself.

did i mention

Version Control:

https://laracasts.com/series/git-me-some-version-control

trust me, you'll love it almost instantly

@Helmchen , LOL. Yes, I saw your reply, and thank you. I was just trying to explain where I'm most comfortable, and least comfortable. About to watch the video now. Thanks again! :)

That should only show how important that is :) Of course, I was aware that you've already seen the first post, but Git just makes the deployment that much easier :)

It's as simple as doing a git clone renaming one file (.env.example) and running php artisan key:generate && php artisan migrate, done. All that steps can be automated.

at least most of the time and especially with smaller applications

Each time you commit to a git branch, it's basically a "new version". You can go back to any previous commit you want (rollback). You can also "tag" versions (like v1.0.1, v1.1.2, etc) at any point in your commit history, but each commit on it's own is basically a "different version".

Like let's say I'm working on a new feature. When I'm done with the feature, I merge it into the master branch. Then a few hours later I discover a bug. I can roll back the version (git HEAD) to the previous commit just before I merged my new feature and everything is the same as it was before.