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
Related
I'm developing web app using CodeIgniter PHP framework. The server I'm working with does not support any type of source control (i.e. Subversion) unless you go to a higher price tier.
I would still like to put the code under some sort of source control. Does it make sense to do the following:
Install git or SVN on my local machine and develop there
Copy changes from my local machine to development directory on the server (using FileZilla, WinSCP, etc.) and test
Copy changes from development directory to production directory on the server
Does that sound reasonable? Are there better alternatives? Thanks!
If you are using svn locally it's a bit dangerous because then you will need to protect also your computer - I think the best way is to work with the commercial sites offer fully supported svn/git - like http://www.beanstalkapp.com/ or http://www.github.com
You could use source control on your local machine (SVN, Git, etc.) and use an open source tool like Capistrano to deploy the code from your local source control repo to your server via SSH. Or if you're limited to FTP, this blog post has a potential solution.
An advantage of using a tool like Capistrano instead of directly mirroring the files on your local machine to the server via FileZilla or WinSCP is that Capistrano will version your deployed files so that, if you end up breaking something and need to roll back quickly to the previously-deployed version, it can be as easy as changing a symlink to the previous deployment directory.
Does that sound reasonable?
Partially, in p.1. But even in this case I'll suggest to have your repository also at some Repository-Hosting (BitBucket, GitHub, Assembla)
For pp. 2-3: your deploys must to be automatic and non-interactive, thus - you'll have to select another tools (for using in post-commit hook of SCM-of-choice)
Somehow better alternative to 2-3 may be:
Use 2 different branches (DEVEL and PROD) as sources of DEVEL and PROD dir
Post-commit hook, which upload only changed in committed revision files to corresponding dir (NCFTP for FTP, SCP with scenario for ssh)
Main development happens in DEVEL branch
PROD have only mergesets from DEVEL
Workflow is SCM-agnostic and scalable to any reasonable amount of branches and developers
I am working on a multi-site Magento implementation and I need suggestions.
I am working on a dual core 1.8ghz machine at work with 3GB ram and have found it to be very slow when using MAMP for my personal development environment, so I have set up a virtual machine using CentOS that mimics the actual staging and production server.
The problem is I have to do my changes, commit them to SVN and then update the repository on my virtual server which is using a crap load of production time. This Magento implementation is a multi site/store so it uses a lot of RAM and I need a stable file system with speed.
I am on a Windows XP Pro machine using WAMP normally but like I said I have found that to be slow. Is there any way I could develop it on my machine without it slowing down every other process?
I have my IDE (Aptana) open and most the time Thunderbird open as well as MySQL Workbench so I have a lot of programs running and the Virtual Machine dedicates those resources, but like I said it it tedious to continuously update the repository.
Can any Magento or expert developers weigh in? I really want to plan ahead for when I get more projects like this, and I would love to hear what some of you other developers do.
Thanks,
Darren
You don't specify that the virtual box is remote, but I'm going to make that assumption here (since a virtual box on your local host would by definition be slower than the machine it is hosted on).
I would suggest connecting to your higher-spec machine remotely to work with the files and testing on that environment. Basically, use it as a development instance and make changes remotely. Then, check in those changes as necessary.
I am very much a Linux developer so your toolchain is a bit outside of my expertise, but you should be able to mount the remote drive as a local network drive, or your IDE may even support mounting it over SSH (which would probably be a bit faster).
Hope that helps!
Thanks,
Joe
EDIT: I should say that, if your virtual instance is not remote, that changes my answer a little bit. Go rent a virtual dedicated machine with some reasonable stats, set it up for Magento, and then do go the above. The monthly cost of a virtual dedicated machine is quite low compared to any hardware technology upgrades you might buy, and it gives you a safe place to break things. The downside to this workflow is that you must be online to accomplish anything.
I develop locally on a Mac using MAMP (and in the past Zend Server). The IDE of my choice is Netbeans. I highly suggest you checkout (no pun intended) Git for doing development work.
I have a server that I use for production and staging. The production and staging have two different databases. A Git central repo also resides on this server.
Essentially, I do my modules and dev work locally on my Mac. I try upgrades and such, then use Git to commit them and push them to the central repo on the server. Once there, I merge the changes into the staging server and test, test, test. If everything is cool, I then pull (merge) the changes into production.
This has served my purposes quite well and I have not had a botched upgrade or anything... if something goes wrong you just rollback the changes in Git. You did make a dump of the DB before upgrading correct :)
As you get more sophisticated you can start using phing to do some automated roll out of your code, but that is another story all together.
Best of luck!
I've inherited a significantly sized internal app at the company I work for. It has two parts. One runs on a LAMP server, the other runs on a WAMP server. There is no source control to be seen.
Currently, developers will log into each server via FTP and just directly edit the PHP files that are there. Or log into phpMyAdmin and make changes to DB schema where necessary.
What is the best way to implement some source control into this situation? I'm not very knowledgeable on how to best setup CVS ans SVN. Would all developers need their own "test system"? Meaning, would I have to setup a LAMP+WAMP enviornment for each developer? Or can they would off a central dev server? What is the best way to deploy changes that have been made?
Developers all use Windows. We also use Zend Studio 5.5 for development.
Thank you in advance for any advice.
It's really not a lot of effort for a developer to have a personal LAMP/WAMP running locally or in a VM. A local dev server is worth having for testing non-live changes in a closely matched environment but it doesn't really scale if all developers are making their changes on that at once.
I'd have all developers committing to trunk in Subversion and then have a stable branch which is automatically (using a post-commit hook) deployed onto the server. Only certain people should have write access to the stable branch to ensure a junior developer doesn't accidentally screw the live server.
That's a horrible way to work on websites, especially with a team. The whole setup should be changed.
The source code should live somewhere else, and then get deployed to the website when it's ready. You could have a script that does the deployment and whatnot (copy the files over ssh, plus any other setup if needed, etc). The point is: no one should ever edit files directly on the production server.
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).
I've read a number of topics in the same sort of ballpark as this one, but in all honesty I'm still not exactly sure on the best approach (as a starting point). I am a solo developer in a small office and I have around 30 websites which are hosted on a linux VPS. I want to start using using version control (probably SVN) and also set up a staging server. At the moment, I do development either locally on my machine before using FTP to upload to the live server, or ocassionally for small changes I edit the remote files directly, which is not an ideal approach.
I'm looking for some guidance on how to improve my development environment. I imagine I should be installing SVN on the web server, which would then allow me to check out versions to my local machine (which would also require SVN i think). Also, if I want to set up a staging server, should I just set up subdomains for each of the live websites, then use these subdomains for showing clients changes to the site before making them live?
Hope this makes sense!
This is what we do at work:
We have a staging server running Apache and a Subversion server. We have a post commit hook that updates a working copy in the htdocs directory, that way, when a developer commits something it automatically gets updated on the staging server, so everyone can see the latest code.
On the client's production servers (the ones we can control) we have the Subversion client installed and the website is a working copy. When we need to update the live site we login to a shell and run svn up. If you do something like this, make sure to limit access to the .svn directories, either with .htaccess files or from the main Apache config.
We have a custom app that manages the projects, but that is only because we're lazy and don't want to setup each project by hand, the app creates the necessary directories and working copies. You could write a quick script to do this.
We never, ever, edit files via FTP on the live site. All in all we have been using this setup for almost 2 years and aside from the occasional conflict on the staging server, we never have had any problems.
You can actually install the SVN server on your local machine, which I would recommend in lieu of installing it on the web server (assuming you make backups). The easiest thing to do, since it’s only you using it, would be to use the file:// protocol, but using svnserve is a little more robust, and the preferred method if you want to take the time to do it.
#Michael, I disagree - I would say it's better to install on the linux vps, especially if you are already paying for the hosting service. I find it very helpful to be able to browse and download stuff from my svn repo wherever I am, from whatever computer I'm on.
#nicky, I started with svn (and version control) several years ago and I took baby steps which made it easier to tackle.
If I had to do it over again, I'd read the svn book to start with. The book is very well laid out and didn't take more than 1-2 days to plow thru.
While you're reading, install svn on your linux vps with an apache front end.
Once you have that up, pick one of your websites and import it into svn. This is how I structure my svn repo. For example, say my repo is hosted at http://mysvn.mydomain.com/svn/:
mywebsite1
- trunk
- tags
- branches
mywebsite2
- trunk
- tags
- branches
Don't worry about creating the perfect structure. It's pretty easy to re-organize especially when you're starting out. After you import a few projects into svn, you'll start to get a feel for which projects should have their own "trunk/tags/branches" dir structure and which can be combined.
For creating test environments, I do exactly what you describe. I use build scripts to checkout from svn and download files into dirs that are mapped to subdomains like "test.clientsite.com" (I work primarily in java and use ant and maven, but I think you can use whatever scripting language you're familiar with).
Once you get used to version control, you'll never go back, good luck!