Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
How to write on production and add features on development
Hi all.
I have a problem with our current TXP development inplementation.
We set up a classic “development/staging/production” environment, but now we have the problem that we would like to be able to add features/edit code in development, but, at the same time, adding posts to just production to avoid redundancy, or worst to be forced to write posts in development and run migration script to production just for posts and only “after” development of new features/edits have been done…
Any advice on how to manage this issue?
Offline
Offline
Re: How to write on production and add features on development
Hi Jukka, sadly, no VCS currently.
I normally use Mercurial, but it was not possible “in illo tempore” to set it up.
We are using (among others) rss_admin_db_manager and adi_prefs plus a custom script to manage migrations.
Do you think using a VCS and a merge+deployment script could be better?
Thanks for your help,
Giuseppe
Offline
Re: How to write on production and add features on development
caruso_g wrote:
Do you think using a VCS and a merge+deployment script could be better?
VCS’s are great even just for the revisions, and for knowing you can go back, but it might not change the difficulties when comes to deploying the content from other location to other. The final process would still be the same, cause same type of conflicts, and involve the same tools.
If you make sure content and code are separated, then it’s fairly possible to some extent. Just don’t touch the content, just deploy the code. And that’s it. As such, only thing changing on the development environment would be forms, pages, plugins, assets and anything non-relational.
Changing categories, articles, images and files then happens only on production. Running the code to production can happen by simply dumping the database as is, minus the tables hosting the content. For tables like txp_prefs (preferences) which are mix of both, you may have to end up using migration script. Also something like cnk_versioning could prove helpful too when importing, and even just for the editing ability.
The problems may come when/if you want to still keep the different environments in completely sync. I would do it by running the just the content from the production to development in above scenario. Content being images, files (directories and the tables from database).
And there are some things you can’t really do, not without running custom migration or synching scripts. One of the problems is adding content on the development environment, as in articles, categories, or images/files. And if the content comes from two streams (and is not always in sync), then you can not use database’s row IDs to detect items. For example selecting an article (or image) by ID is no no, if content comes from two streams and isn’t in sync.
What I was even saying… mumbling mumbling mumbling. Train wreck post. I hope there is some sense (likely not).
Last edited by Gocom (2011-08-19 09:38:47)
Offline
Re: How to write on production and add features on development
Do you think that using cnk_versioning can help?
I mean, if I continue to write posts on production, while editing code in cnk_versioning folder, I should be able to “just” move cnk_versioning folder files to production, and, just if I really need it, create a reverse script to update development db with production one, right?
That way I could also versioning cnk_versioning folder and, probably, create an easy script to deploy code on commit.
What do you think about?
OT
That said, it is really bad that TXP keeps all in textpattern table. If it could keep code separated like cnk_versioning does, it not only would permit versioning your code, but, above all, it would be possible to build a system to create a themes installer/management and, then, create a market environment that would probably spin TXP off to the masses. Just my 0.02€
Offline
Re: How to write on production and add features on development
caruso_g wrote:
I mean, if I continue to write posts on production, while editing code in cnk_versioning folder, I should be able to “just” move cnk_versioning folder files to production, and, just if I really need it, create a reverse script to update development db with production one, right?
Correct, that would work. Cnk_versioning imports pages and forms, and moving the single templates directory from one environment to other would be enough — well, for forms and pages.
Offline