Hello I have been wanting to get into working with a framework and Laravel seems like a decent one to try.
I have seen a lot of tutorials that tell you how to setup Laravel locally with Homestead or variants.
I am wanting to install and setup Laravel on my dedicated remote server with my hosting company. From there I want to be able to work with it on my local MacBook or MacPro.
I have not been able to find a good tutorial to make this happen in the fashion I want to do it.
I work with PHP and related daily but usually login to FTP and edit files with TextWrangler and save them and go about my day so my methods are dated and not efficient.
One side note is that I also have a Dell PowerEdge server running CentOS and VestaCP in my office as my development server so nothing is done locally per say (on my own computer) so the question and answer will apply to both my remote server and my remote but local development server.
Any suggestions are always welcome.
Best Regards,
Bradley
Assuming you have full root access to your remote servers, you should install composer on them and install Laravel in whichever way suits you. Then you can edit your project files just as if you were working on it locally.
Seriously though, the biggest thing you should add to your development arsenal (in case you haven't already) which will make your development process so much more resilient is Git.
Set up a free Bitbucket account, get a free Git client, and learn how commits, pushes, pulls, branches and deployments work. The easiest approach for deployment is to use a service such as Envoyer.
That way you can develop and test locally (even if 'locally' is a remote machine) and not really have to worry about breaking your app by making a mistake in controller or something on the live server.
Related
Is it possible to serve my production domain through Laravel valet service??
I have my domain which I have purchased but I want to share my website through valet.
Laravel Valet is pretty much exclusively for local development and not recommended to run production code. It's essentially a lightweight shortcut to allow you to start developing in Laravel quickly. It is also exclusively maintained for a Mac - I mention this as most production websites are run on a Linux or Windows environment, and support for running on a Mac would be relatively small. (https://www.quora.com/What-is-the-Server-Operating-System-market-share)
Off the top of my head, this is also not a good idea as Valet proxies all folders that you run valet park to http://[folder_name].test URLs, which could theoretically open up security holes if you accidentally moved something in your local development environment into the parked folder. Essentially, it opens you up to a bunch of security issues, that just being one of the first ones.
I know it's tempting to want to just publish a site as everything "just works" on your local environment, but I would highly recommend finding a dedicated host for your website running in production. There are a plethora of hosting packages allowing you to run your Laravel application safely and cheaply.
Shared hosting is alot easier then Valet. I spent a good 4 hours trying to get valet working on my mac cause I had about. 5 versions of PHP. If you use Valet on a production server then you going to have to pay more for a more dedicated server that will allow you to install the software. And your getting a less productive enviroment. Your basically paying more for less quality. A shared hosting site will atleast provide support to fix any server issues non related to your web app and your paying less.
I'm the lead developer at a startup and we currently have the following setup:
- Development Server
- Staging Server
- Production Server
- Paid Subversion Hosting
- My local machine
- 2 other developers' local machines
Where is the best place to host the CI server? On an entire new server? Or is my local machine sufficient for this?
Definitely not your local machine. I'd suggest a separate server unless you don't mind slowing down your dev server.
I say not your local machine because the last thing you want to be hindered by is builds. Nothing is more frustrating than a slow machine. And you should generally keep official builds generated off of a separate server.
Generally not local machine (when other options are available) as you mostly want to have the same "stuff" installed (or not installed) on the build server as you have on the production server, so that whatever is running on the the build server is running in as realistic a scenario as possible.
Speaking from a .NET point of view, this means that I don't want (for example) Visual Studio running on the build server, ruling out my local machine.
It would also be a good idea to be sure someone on your team has access to the machine and can perform actions on it, thus potentially ruling out the hosted solution.
Aside from that, as long as it's on a box with a half decent spec, I don't think it really matters.
I would put it at the development server, staging server, or the paid subversion hosting instance, if possible.
I am totally new to programming and to some new technologies. Right now I am using WAMP on my Windows Vista. For me, using WAMP is very convenient because I am gonna install once and no need for complicated configuration.
I was OK with it until someone told me that it's not good to use WAMP, EasyPHP, XAMPP, and MAMP because if one of the components such as MySQL crashes it won't work anymore. He said that it's best to install them separately and do a pain in the ass configure later.
Please advice.
For development and small low volume sites WAMP is just fine!.
If you are not reasonably experienced with installing configuring Apache, php and whatever SQL you are using then a WAMP package is still the better option as a suboptimal configuration is better than a broken one.
Once you are deploying to production and need to deal with larger transaction volumes and security issues then you should really install the components separately and custom configure for your particular needs.
However realistically if you get as far as a small/medium volume production application it will probably be deployed on a rented application infrastructure where all this will be done for you.
So yes stick with WAMP. Time is better spent getting your App right than learning the esoteric settings in the various config files.
WAMP has a clear goal: to provide a usable PHP environment directly out of the box. 0 configuration needed. 0 knowledge needed. You click and it works. If you are a newcomer, this is an obvious choice.
Configuring complex software like Apache and PHP is really difficult for a newcomer. If you're not actually going to use WAMP in a production environment, there is no reason you would have to touch the default configuration.
Making a separate installation for each of those components just doesn't make sense if you're discovering programming. When you're more experienced, you'll certainly enjoy editing obscure configuration files on a distant machine.
My advice is to go for WAMP on your development PC.
I don't think that the 'crash argument' is valid. It makes no difference if you install a bundle or single component - the problem is find the cause and to fix it. The bundles are designed for an easy start, the price to pay is that the configuration isn't meant for production use. I would prefer to learn using a local bundle and apply my knowledge/skills when I configure a production server (without any pain, because then I can).
WAMP--Windows Apache MySQL PHP
XAMPP--X(Multi OS) Apache MySQL PHP Perl
Wamp is better for newbies, To install, customize easily and learn the basic things in user friendly. Mainly on enabling the dll's in wamp is more easy than Xampp. But it will create many problems as kind of, when we restart the server it may not restarted properly and you need to do additional thing as restart your system or need to re-install wamp. The main drawback is, it support Windows Alone. Normally nowadays everyone prefer to go with Linux server as it have more security purpose. Hence if u develop using wamp, its useless for Linux Production Environment.
So i would suggest Xampp and its also a developer's choice.
It have more features than Wamp,
they are:
Tomcat
Perl
Supports Multi-OS
Filezilla FTP
PHP4
PHP5
It is better to restart the server separately for MySQL, Apache, Mercury, FTP.
For enabling the dll's in Xampp is not a hard task for developer and its a stable server.
Is there anyone out there that can share experiences with the various flavours of running svnserve on Windows. I'm using it mainly for a small hobby project that I share with friends, so it will run on my desktop.
Using the Collabnet Subversion Edge seems a bit heavy weight. Any drawbacks in just run 'svnserve'? I recently found VisualSVNserver which seems to add some easy administrative functions.
I have good experience with VisualSVN server, very easy to set up and configure user accounts.
It is also very easy to upgrade, just run the latest installer and you're done.
With VisualSVN you can run HTTPS with a self signed certificate. If you just run svnserve you're left without encryption and that is not recommended if you plan to access your server from the internet.
Keep in mind that whatever solution you choose they all use standard svn as the backend and you can easily move your repositories from one solution to another.
If you plan to make your project open source you can host your code at sourceforge or codeplex.
my project is a PHP web application. This applies to my test server (local), not production server! I am also the solo developer on this project (however, that may change in the very far future). Also, all my source code is committed to a repository and the production server gets the source code from the repository.
I do my development in Windows while my test server runs on Ubuntu (perhaps you can also recommend me another distro that is easy to use and can serve as a good web server). I need an elegant way to interface between the two environments. Currently, I do my coding in Windows and then FTP the changed files to the test server. However, this is quite cumbersome and tedious since I have to manually go to my FTP client each time. Suggest me something elegant please! Perhaps FTP sync? or OpenVPN (where the root www directory on test server is acts like a folder in Windows)? Thanks for your awesome time!
Easiest would be in Ubuntu, right click a folder then click "Sharing Options", then share the folder. In Windows, connect to the share, and work on that copy.
If you're using version control, using continuous integration like Hudson ( http://hudson-ci.org/ ) would help if you create a task that builds/exports the website for the testing server. This approach would be better in the long term, but you'll waste a day setting it up initially.
I prefer SFTP to FTP.
That said, ExpanDrive lets you map SFTP servers to local drive letters, which then means you can use any text editor to access your files directly on the test server, or use other mechanisms to keep the files in sync. Since they show up as two local drives, you can use just about any product out there.
If you want to use FTP, you can just map the drive in Windows Explorer. If you open up My Computer, then go to Tools > Map Network Drive, you can map a FTP server folder to any local drive. Just type in the address as the folder, ie. ftp://mscharley#192.168.0.10/htdocs
This will atleast save you a trip to the FTP client...
Is there any reason you couldn't just test on your local computer? At my job, we all develop and do developer testing locally, most of us using Windows. Our production and test servers are all linux based. Working locally is really nice, because you don't need to worry about making changes on the server with every small change.
Another option would be to create a checkout or working copy of your code on the server, and then run svn up or svn export (or equivalent using your version control software) each time you change the code on the server (assuming you are sshd into the server). This is kind of slow, but it's easy. The other option would be to write a script that goes through the svn logs for the recent commit and only exports or updates the ones that changed. This is much faster, and for all I know, there is already something out there that this.
Finally, some IDEs allow you to edit files live over ftp\sftp. Basically the IDE downloads a copy of the code and then reuploads it when you save.
Currently I develop on windows (PHP) as well and deploy on a Linux box for testing and production. This is how I do it.
Set up a local development server with e.g. WAMP.
Set up your code base in version control, e.g. Subversion.
Checkout your code base onto the testing/staging server, not just only on your local dev. environment.
In the early stages of development you want to deploy to the testing environment A LOT to sort out any discrepancies between your windows and linux environments. When your programming efforts turn more into program flow type programming this constant testing will probably slow down. But still take the effort to test on a regular basis.
To test your code base on staging do an svn update. I just log in with an SSH session to do this. A key thing here to note is that you do not have to make any config changes to your code base. If you do need to make config changes to your environment on staging it worth while spending the time to SCRIPT this process rather than this being a manual process.
Do the same for production. I use an Subversion check out on production as well. Make sure you set you .htaccess file to deny access to your hidden .svn folders and script the deployment especially if there a config changes necessary.
Some ideas:
Use a server environment under windows (e.g. EasyPHP).
Use a development tool that can save over FTP (e.g. ultra edit).
Use a network drive connected to the remote machine via FTP.
Use a network drive connected to the remote machine via Samba.
Run a linux distro inside a virtualization tool (e.g. virtual box) and write from the windows host to a share directory of the guest host.
Use dropbox to sync files between machines (there is more a hack than an "enterprise" solution).