Hi,

We run a similar setup.

I also run Windows on my dev machine, my colleagues develop on Linux and
Mac.

When ever we need to show a client or a PM some work, we push it to a
staging (test) server, so there is no issue in keep all websites running
locally.

We host our Git repositories on an internal server, as its generally faster
and more secure and Github. And also use Git to deploy to staging and live
servers.

We have developed a few scripts to recursively run Git commands over a set
of directories as our website are generally made up of many repositories.
We also are starting to use Composer for external libraries.

We try to make our database changes in incremental SQL files, and commit a
combined SQL file for each environment. This way when doing a deployment we
can run a diff on the combined SQL file to see what migrations need to be
run. We also use Toad for MySQL for double checking the our schemas are
synced.

When I need to sync content back from from another server I typically use
mysqldump piped through ssh which is as simple as 1 command.

David Neilsen | 07 834 3366 | PANmedia ®


On Mon, Oct 29, 2012 at 9:52 AM, Harvey Kane <[email protected]> wrote:

> Hi Everyone,
>
> I was wanting to start a discussion on how people manage their dev/test
> servers. I'm thinking of changing a few things that I do and thought it
> would be worth canvasing for ideas first.
>
> So I'll get the ball rolling.
>
> Firstly I like to develop on my local Windows PC - it's just faster and
> easier for chucking files around. So I use wampserver + a paid no-ip
> account so I have a domain that points to this server. This means project
> managers can look at the site while I'm working on it (via
> clientname.mydomain.com) and WAMP is handy in that it lets you run
> different versions of PHP/MySQL side by side.
>
> Once the job is ready to show to the client, it goes to a different dev
> server on a properly hosted linux box. Git to transfer the files, database
> is imported manually. I won't always do this, but it's useful where the
> client is likely to take weeks or months to upload content and approve the
> work etc. The problem with WAMP is that all the dev sites go down if I
> switch php/MySQL versions for a day to work on another project, which
> happens quite a bit.
>
> When we go live, we use git to transfer the files to production server and
> again move the database + content file uploads manually. Command line git
> on the production server is great. I find it very handy for making little 2
> minute tweaks to the live site and then pushing them back onto the dev
> server. For larger ongoing changes, I'll do those on the local wampserver.
>
> I use github for managing the git repos which works well, but the 50 repo
> limit is going to hit sooner or later (I don't know how pricing works after
> 50 repos) so I'm giving thought to self-hosting this. Would welcome any
> comments on that.
>
> One thing which is a constant struggle is developing on a dev site with an
> outdated database / content files. You can ask for approval just on the new
> feature you developed, but the client always comments on product images
> missing, or a page having the wrong content etc. I'd be interested to know
> how others work around this - perhaps a scripted way of pulling the
> database + user files down from production to dev?
>
> Anyway, interested to hear what other people use, and the pros and cons
> etc.
>
> Harvey.
>
> --
> Harvey Kane
>
> Phone:
> - Auckland: +64 9 950 4133
> - Wanaka: +64 3 746 8133
> - Mobile: +64 21 811 951
>
> Email: [email protected]
>  If you need to contact me urgently, please read my email policy
> www.ragepank.com/email/
>
> --
> NZ PHP Users Group: 
> http://groups.google.com/**group/nzphpug<http://groups.google.com/group/nzphpug>
> To post, send email to [email protected]
> To unsubscribe, send email to
> nzphpug+unsubscribe@**googlegroups.com<nzphpug%[email protected]>
>

-- 
NZ PHP Users Group: http://groups.google.com/group/nzphpug
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]

Reply via email to