Best practise to implement changes in PW from development to production

[thlinna]

I am running development server where I test and try the changes in fields and templates of ProcessWire. The php files are stored in git@bitbucket. 

The part of managing changes and versions of php code itself via git is quite straightforward, as I presume we all know. However, I have not been able to come up with decent way of moving the changes in fields, templates, modules and settings from development to production other than repeating them, step-by-step, manually in production environment via the admin back-end.

Perhaps there is more sophisticated way of transferring these changes?

[AndZyk]

Hello @thlinna,

haven't tried it out for myself yet, but I think @LostKobrakai Migrations module is what you are looking for. 

Regards, Andreas

[owzim]

Hi @thlinna this has come up a couple of times, here's a selection of topics, perhaps you can find something useful in there.

Tip: use google search for searching the forums every now and then, I find it spits out more useful results at times:

search: sync live dev site:processwire.com/talk

 

[thlinna]

Thanks you so much for the insightful replies, @owzim and @AndZyk. Of course I tried to find something with PW forum search, but was not happy with the results I found.

For my production site has active content creation and new content is stored in database all the time. My development environment is a snapshot of certain time in production, so it's content start getting outdated from the second I take the snapshot. 

I looked promptly at @LostKobrakai's Migrator-module, but the use of it felt quite complicated, especially for newbie and for beta status. I hope no-one would not take this statement offending, but I feel sometimes tutorials and forum thread information require more indepth understanding of PW itself. As a newbie one is still trying to overcome the steepness of the learning curve. If one hits a wall, it may take plenty of time to overcome it. PHP environment is quite different from java or c#, so my coding and setup skills for the latest devops style coding is shallow.

Maintaining PHP code, CSS and JS is a OK with Git, but how to move created pages from dev to prod is not that simple anymore. As @Michael Murphy pointed out, in another thread, one way is by exporting/importing fields and templates. But does it export the pages or content that I have created in the dev environment in to the fields?

[owzim]

@thlinna I have been working on a module, a more non-dev-friendly approach the migrations module for about one year (on/off). I am actually using it all the time but it's not ready for public. It has many bugs I know how to circumvent and next to no documentation. It's similar to JSON Installer module, but more powerful and the data files are written in YAML.

Perhaps JSON Installer can be of help to you.

[szabesz]

@thlinna I do not know if it will be of any help, but I myself do not migrate any db at all. Instead I build my workflow around this: http://tltech.com/info/mysql-via-ssh/

I put together a bash script to completely automate the process, and normally I can clone the live db to my local machine in seconds (small databases...). This way I always have to work on the live site to make all the necessary changes, afterwards I have to clone the db, but it is an easy to follow workflow and dead simple  It might be too simple for teams, but a solo developer cannot go wrong with it, at least I'm quite happy with it, I got used to working this way. Sure, I have never had to work with really big databases, but these days even transferring dozens of megabytes does not take long.

[owzim]

@szabesz sometimes live changes break the existing site if you don't have the necessary files (e.g. template files). Also, working on a live site's structure ... breaking stuff. Rather locally.

It's kind of cumbersome, but this is how I do it: I lock the site for edits (in consultation with the client of course), clone the db, make changes locally and update the db when finished.

Here's a small recipe for adding a maintenance mode.

[szabesz]

Yep, true, of course, it is not always just about adding a field here and there... So while my "migrating workflow" is simple, it comes with the issues you mention, so yes, sometimes I do have to try things out on my machine before I redo it on the live site, but this does not happen every day. And also true that "maintenance mode" with kindly locked out users might also be needed sometimes.

To get around the problem of missing files, I use Beyond Compare, the fastest an easy to use diff tool out there. When it is set to e.g. ftp 8 simultaneous connections, it can deal with a site in 10-30 seconds or a few minutes, depending on the number of files. I only use git to manage my own code.

EDIT: My bash script can also migrate/clone complete sites in a minute or two, just in case a need another "branch" of the whole site to work on something that takes long and should not interfere with my regular mirrored version of the live site.

Edited November 29, 2016 by szabesz
typos

[FrancisChung]

Right now, I use rsync for code deployement and about to install a bash script running mysqldump and mysql for DB backup and deployment. I run Procache so in the midst of writing some php modules that reconfigure the site from Dev to Prod.

Hopefully I'll have a script that ties everything together soon.

If this is of interest to anyone, I could post it once I'm sufficiently happy with it?

 

 

[szabesz]

13 minutes ago, FrancisChung said:

If this is of interest to anyone, I could post it once I'm sufficiently happy with it?

I'm interested  Thanks is advance.

[thlinna]

1 hour ago, FrancisChung said:

If this is of interest to anyone, I could post it once I'm sufficiently happy with it?

Interested too!

[LostKobrakai]

19 hours ago, thlinna said:

..., but the use of it felt quite complicated, especially for newbie and for beta status. I hope no-one would not take this statement offending, but I feel sometimes tutorials and forum thread information require more indepth understanding of PW itself.

That's mostly because it's not a simple problem to solve at all. Merging of changes happening in two independent systems cannot work simply by clicking a button. There are various ways to make it work, which all come with their own kind of backdraws. With each project having different goals/needs it's a matter if choosing the one giving you the least pains, while helping you enough to make it worth. 

Also I'm not sure if I missed some beta statement in my modules topic, but it's really stable. Any upcoming changes should only affect the accompanied cli tool. Also I've it in production usage for over a year now with no issues in the latest months.

[szabesz]

6 minutes ago, LostKobrakai said:

Also I'm not sure if I missed some beta statement in my modules topic, but it's really stable.

You might want to remove the beta status. No software is perfect, however if it is stable, why not give it 1.0.0?  

[thlinna]

4 hours ago, LostKobrakai said:

Also I'm not sure if I missed some beta statement in my modules topic, but it's really stable. Any upcoming changes should only affect the accompanied cli tool. Also I've it in production usage for over a year now with no issues in the latest months.

Oops. My bad, I apologize. My assumption was based on some old forum threads.