I’m working with another team member and they are reside in a different US State. We are working to convert an existing static e-commerce site to a WordPress site.
I want to have a DEV install of WordPress so that we both can access it easily. I’m going to do the majority of the coding. He will help with some HTML/CSS and a lot of data related work. Either manually entering in items or figure out some import method.
Here are the options that I’ve thought through and it makes sense to do Option 2.
Option 1
- Install WordPress on my laptop
- Install DB on my laptop
- Configure my router to allow incoming HTTP requests and redirect them to my laptop
- When we want to deploy to PROD, follow steps to move code to server, dump the DB and import into DB on server.
The downside of this is that if I turn my laptop off, or if something goes wrong with my cable modem, my partner won’t be able to access WordPress.
Option 2
- Install WordPress on server at the current domain in a subdirectory, ex: domain.com/wordpress
- Install DB on server
- Password protect the directory to stop someone or some bot that tries to go into the directory
- When we want to deploy, update index.php
Are there other Options that could also work?
Version Control
I would also need version control. I could put the install under SVN.
How do people version control databases with the code. Ideally they both should be in sync.
I think you should go with option #3; either of the two other options will lead to heartache in my experience. You’ll end overwriting each other’s changes and other issues.
Option #3
You both set up local developments environments and you use a Subversion repository to keep things in sync. I use a free account at Unfuddle with gives you two logins and subversion repositories as well as a ticketing system and task and milestone tracking. Unfuddle works well for me but of course there are many other options, Unfuddle is just the one I know that works well for me.
As for the database, it’s very hard to manage databases in source control. What you really have to do is write scripts that rebuild your database from scratch and then version them. Ironically I’m working on exactly that for tomorrow and I asked a question here in hopes to get someone to help me but instead it looks like I’m doing it all myself so I am documenting what I’m getting done in an answer. You can read about it here:
- Initialization Script for “Standard” Aspects of a WordPress Website?
While the above question/answer talks about initializing a new database using standard aspects you could actually do the same with existing data, it would just be more work.
Thus far in my development I’ve always been able to simply do a forklift upgrade of the database but I’m getting to the point I’ll need to manage existing data. So it looks like over time I will be building tools to export data to scripts and/or files where I can easily merge new work with current data. Sounds like you need the same. Hopefully others will come along and we can all handle a piece of this problem; as they say: “Many hands makes for light work.”
Sadly my answer is not simple regarding the database but as far as I’m aware this has always been an issue for deployment of database-related systems and scripts that you can test and submit to version control are really the only known way to handle it.
