I currently have a problem with how to setup my virtual environment for my LAMP stack. The site I'm developing is a web application written in PHP and uses MySQL for the database. Right now, I have a single VM running inside Virtualbox with CentOS. I run the web/mysql server in it and have my code folder setup with GIT.
The host OS (Mac/Windows) currently is setup with a SAMBA share to access the code inside the GIT folder on the VM. From this, I use SourceTree and PHPStorm to manipulate the files and make commits. Permissions on the files/folders are set with a force mask (which doesn't seem to be possible with NFS)
(Samba server on CentOS(guest os), Samba client on Windows/Mac(host os))
The problems occur on occasion when I run my environment like this. I've had my GIT repository have weird errors and corrupting (HEAD detaching, index files corrupting / being too small, other .git files corrupting). There is also an issue where the file names are case insensitive and the CentOS guest OS runs it as case sensitive.
Ultimately, my questions is: How can I setup my development environment to execute the code inside my CentOS Guest OS, have file permissions not be a hassle when I'm commiting/executing, allow me to setup an environment that will match my multi-server environment (ie. multiple Virtualbox instances), and have it run into no or minor problems as if I was just running it all under CentOS for development?
I would prefer to be able to run VirtualBox, be able to develop my software using my PHPStorm/SourceTree applications on my Host OS, and avoid any problems that lead to corruption of my filesystem in GIT.
Related
I want to deploy my Laravel project which has a Per-project Homestead inside it (not the global homestead). Some Vagrant and all Homestead files are included inside my Laravel project. This is the first time I'm deploying a Laravel application, and I really cannot find any information about files and folders that may be excluded from the deployment (Especially for a project with a per-project Homestead inside it).
I guess, .vagrant, tests, .env.example, .gitattributes, .gitignore, after.sh, aliases, Homestead.yaml, phpunit.xml, readme.md, and Vagrantfile files and folders may be excluded. Am I right? And what about the vendor folder (There are some Vagrant, Homestead files inside, as well, like e.g. homestead, homestead.bat inside the vendor/bin folder, or the whole homestead folder inside vendor/laravel).
Ideally, you would use a VPS or deployment server like DigitalOcean. However, as you stated you are using a shared server, the directories/files you will need to upload to the root directory of your server account are:
app/*
bootstrap/*
config/*
database/*
public_html/*
resources/*
routes/*
storage/*
vendor/*
.env
The remaining .files are for dependency management and development tests, and since you likely won't be using any build processes or Continuous Integration on a shared server, you won't need them.
Note: make sure these are in the root directory and the only publicly accessible directory is public_html. By default, shared hosting servers already have this restriction. Uploading the Laravel project as you have it will overwrite the website's current public_html directory, so make sure to back up anything you may have there currently.
Update
Frameworks like Laravel are designed to use root/command-line access to assist with deployment and server management. This is the advantage of frameworks. Shared servers do not typically allow users root access, so you end up having issues like yours, where deployment is a manual upload instead of a CLI command through version control.
vendor contains all of the dependencies your app is relying on to operate (Eloquent, Doctrine, Flysystem, etc.), so it won't work without the vendor directory.
You should deploy from version control, and by default that should exclude .vagrant and Homestead.yaml everything else is safe to leave in.
I was enjoining about getting a Network Attached Storage (NAS) so that I can work on dev sites from both my desktop and my laptop without duplicating files and always having the most current file (just in case I forget to save). My question is if I put sites on there that uses php, would I be able to run the sites off of the NAS as I would with MAMP / WAMP? Or would I still need something else to make that work?
The point of a NAS is to share files over a network. This is usually done via Windows File & Print Sharing (aka Samba aka SMB) which is supported on most platforms.
Some NAS devices might allow you to run a web server (particularly if you can install custom firmware), but it is a poor choice of platform to run anything remotely complex in terms of web server stacks.
You can certainly store your development files on a NAS, and then access them from webservers running in both your development environments.
… but that said, I'd look at using version control software (Git would be my preference), keeping your repository on the NAS and getting into the habit of saving, committing and pushing. It makes things more manageable in the long run. (You could also use a service like Bitbucket or Github and dispense with the local NAS entirely).
You could also go a step further and run a server with CI software on it that monitors your repository and automatically pulls updates from it, runs your automated tests, and then updates a local test server.
I am assuming you use windows(it's easier to do it in mac i think) with wamp what you can do is mount a network drive to w:\ let's say. Then create a virtual host that points to a folder in W:\ drive.
With mac all you need to do is mount the remote folder share to your mamp directory and all should work as you want.
Though personally I think this is a terrible idea and would much rather suggest you to use a VCS(version control system) to share code between multiple places. Lots of them are designed with this problem in mind. And it provides nice history about your code at the same time. If you want to do some research look at GIT(the most popular, currently) bitbucket has free private repositories. you can look into what a VCS can do here https://en.wikipedia.org/wiki/Version_control
I am trying to set up Jenkins to run our Cucumber features. I am a little lost when it comes to setting this up. Here are some details of our setup:
Cucumber features with steps written in Ruby and PHP (using Cuke4PHP)
PHP application (which often links to other PHP applications)
Using Capybara and Selenium to exercise Javascript
In development environments, since our apps need to link to each other, we set up apache vhosts with domains like http://developername.dev.exampleapp.com
How should I set up this Jenkins environment to run our cucumber tests?
It seems like you would want to set up a virtual machine using VirtualBox or something in order to set up an environment similar to your production environment and serve the project from that virtual host. But then do you run the tests outside the virtual machine? Or do you run the tests on the virtual machine and report back to Jenkins? Do you set up virtual hosts when you provision the virtual machine? How do you set up your project to use an isolated database? How do you run your features in parallel so they don't take forever? If someone could shed some light I would greatly appreciate it.
We have recently started using Vagrant to setup a development environment on virtual machine in which we use folder sharing between host machine and guest Vm for application source code and application database itself is on Virtual machine. We haven't implemented with CI yet though.
For setting up your application environment for a build, you can use Vagrant to setup your applications environment. And assign a ip for your Vm which can handle Virtualhost for that ip by itself.
For running the tests, your selenium/acceptance tests should run from your host/build machine, considering a client and server architecture for you applications as pointed by Amber. But unit test should run on your VM itself. I don't have much idea about running features in parallel. But will share my experience once we have implemented whole process into CI.
Do you have your clients run their browsers on your production servers? (Hopefully not - hopefully they run them on their own computers!) Thus:
The server VM is the equivalent of your production server, so it's not where the tests should be running - Selenium tests run in the browser. Depending on how many browsers/what kinds of browser setups you want to test, you can either set up separate VMs with OS/browser combos to run the tests, or you can run them outside of a VM on a standard browser install.
I would like to build an 'ideal' lamp development stack.
Dual Server (Virtualised, ESX)
Apache / PHP on one, Databases (MySQL, PgSQL, etc) on the other.
User (Developer) Manageable mini environments, or instance.
Each developer instance shares the top level config (available modules and default config etc)
A developer should have control over their apache and php version for each project.
A developer might be able to change minor settings, ie magicquotes on for legacy code.
Each project would determine its database provider in its code
The idea is that it is one administrate-able server that I can control, and provide globally configured things like APC, Memcached, XDebug etc. Then by moving into subsets for each project, i can allow my users to quickly control their environments for various projects.
Essentially I'm proposing the typical system of a developer running their own stack on their own machine, but centralised. In this way I'd hope to avoid problems like Cross OS code problems, database inconsistencies, slightly different installs producing bugs etc.
I'm happy to manage this in custom builds from source, but if at all possible it would be great to have a large portion of it managed with some sort of package management. We typically use CentOS, so yum?
Has anyone ever built anything like this before? Is there something turnkey that is similar to what I have described? Are there any useful guides I should be reading in order to build something like this?
OK, the way we were running development LAMP setup at my previous job, was like this. A single server running both MySQL and Apache. Each developer is assigned an IP address on the server (the machine is running multiple IPs on the same interface, all IPs are on the same subnet), so each developer can have at least one IP-based virtual host and as many name based as they want (our web site used SSL, so we needed separate IPs, wigthout SSL, you can get away with a single IP and name based vhosts). We had local DNS server serving wildcard A records for each developer in this manner *.john.dev.company IN A 10.1.1.123, where 10.1.1.123 was IP address assigned to John. This way John could define as many name based vhosts as he wanted and they would all get resolved correctly as long as they all ended in john.dev.company (like project1.john.dev.company). Each developer had their own apache config file with their virtual hosts in it and we used Include directive to pull all these files into the main Apache config. The permissions were set, so these config files would be editable by respective developers and each developer had a soft link to their config in their home directory. Also, every developer was allowed to use sudo to restart Apache. The downside of this setup was that once in a while a particular dev would crash entire server by screwing up their config file. We used common database, since everyone was working on a single project, but it shouldn't be difficult to setup multiple individual databases.
My take on the issue, i don't think it covers all of your requirements, but it's pretty close:
Have a CentOS server with LAMP stack ( yum install apache2 mysql php etc. ) - or 2 servers one httpd and one mysqld
For n developers have n folders with n virtual hosts www.developer-n.com on the host that runst the Apache server
Each developer mounts it's server folder (say //192.168.0.1/home/developer-n/www) on the local machine via CIFS in the local-station's /etc/fstab and edits the files from local machine yet runs them on the (unique) server
Each developer mini-environment is tweaked via .htaccess
So we are pushing to create good processes in our office. I work in a web shop that has been doing web sites for over a decade. And we don't use version control. I know! It's bad, not my fault. I'm the guy with a SoftE background pushing for this at a minimum.
The tech lead has been looking into it. We all use Mac workstations and mostly use Coda for editing since it is a great IDE. It has SVN support built in but expects it to work on local files. We're trying to explore mounting the web directory as a local network drive with an SFTP tool.
We are a LAMP shop, BTW.
I am wondering what the model is here. I think we have typically would checkout the whole site to our local machine where we have apache running and then test it there? This isn't how we work yet, we do everything on the server. We've looked at checking things in and out, but some files are owned by apache and the ownerships change when I check them in, because I'm not apache.
I just want to know a way to do this that works given my circumstances. Would be nice to not have to run apache locally.
You might want to checkout the Coda mailing list and ask there. Lots of Coda enthusiasts there with specific experience.
If you don't want to have to run locally could make Apache on your server run a copy of the site for every developer, on a different port per person, and then mount those web-roots to the local macs and make that the working directory. If you're a small shop that's not hard to manage. I find that pretty easy to set up and saves a lot of resources on the local machines. The one-site-per-person helps to avoid conflicts with multiple people working on files at the same time.
What I'd additionally recommend is to have a script that gets the latest changes from SVN and deploys the entire site to the production server when you're ready. You could have that script change permissions on appropriate files/folders as needed to be owned by Apache. The idea once you're using source control is to never manually edit the production files -- you should have something that deploys it from SVN for you.
A few notes:
Take a look at MacFuse / MacFusion (the latter is the application, the former is the library behind it) to mount remote directories via SSH / FTP as local ones.
Allow your developers to check out into their local environment (with their own LAMP stack if they're savvy), or look into a shared dev environment with individual jails. This way your developers can run their own LAMP stack (which you could deploy for them on the machine) without interfering with others.
The idea being, let them use a workflow that works best for them, to minimize the pain in adapting to this change (if change management might be an issue!)
Just as an example, we have a shared dev server where jails are created with a single command for new developers. They have a full LAMP stack ready to go, and we can upgrade and re-deploy jails easily to keep software up to date. Developers have individual control to add custom settings / extensions if they need it for work, while the sys admins have the ability to reset everything when someone accidently breaks their environment :)
Those who prefer not to use jails, and are able to, manage their own local environments (typically through Macports or MAMP).