I’ve recently discovered Vagrant, and I like the idea of it. My problem however is that I’m struggling to figure out how to fit it into my workflow, or even if it’s necessary.
On most projects I’m the only developer. Most of the projects I work on are either bespoke web applications, bespoke CMS websites or API’s for mobile applications. Currently I have a development server in the office which has an external URL. I’m using PHPStorm and have each project setup to auto-upload to the development server. This way, as I’m working clients can see progress, or in the case of API’s, the app developer can begin to integrate their app with the API.
If I bring Vagrant into my workflow, it would essentially mean having two development environments. One locally (vagrant) where I make changes test them etc, then when ready transfer the changes to the web accessible development server. I don’t know if it’s just me, but this seem overkill surely?
When I read articles on the web, many of them insinuate that you’re not doing things right if you’re not developing on a local VM.
I’m just wondering what other peoples thoughts are on using Vagrant, and in a similar situation to me, do you use it or another VM? is it overkill or should I be using it as above?
I moved your topic to General Web Dev, as I think it will get more notice there, and this does sort of flow into a “developer workflow” discussion versus a “server configuration” one.
I’m still new to using Vagrant myself. I’ve used it a couple of times now and I enjoy it, but I only enjoy it when there isn’t a dedicated development machine for the given task. Seeing how you have one and you are a sole developer, your need for it is much less.
The point where you would seriously want to consider using Vagrant if any of the below come to fruition:
Complex setup instructions are needed to get a dev environment operational (you do it once and forget about it, as the state is stored)
Multiple developers on the project (as it gives a way for every developer to have an identical environment)
You have software that doesn’t play well with others (CMS 1 doesn’t like it when CMS 2 is also installed, for example)
I’m sure there would be other reasons, but those are the ones that generally get me to use Vagrant and invest my time in setting it up properly on a given project.
The external server is typically called a “dev” or “staging” server. In a multi team environment you would never (with exception) work directly on that server. Instead you would work locally on a vm than publish those changes to the external environment. The tricky part of course is publishing changes from local to a another server. In a one person team this could be as simple as ftp over the files. However, in more robust set-up this is a task currently covered by dev operations teams. One of things dev operation team is responsible is putting in place a system to sync local work to the various environments that might exists on external servers. The processes can be as simple or complex as your set-up requires but commonly include pushing a repository (git) and using scripts to sync the development/staging/prod server with the repository. More times often than not you also need to sync media assets which don’t belong in a repository. That can be handled via standard ftp or a more robust system like aws dependent on needs. The other issue is installing software on the remote box like adding php libs, etc. That can be handled with system such as; chef or puphpet. Again though this is a very robust, automated way to handle the problem. For a one person team it would be best to just do it all manually on the dev servers via ftp and manually installing packages, etc when needed rather than using a deployment server like chef or puphpet but those are essentially the mecca.