How can I easier update my application to server using codeIgniter? - php

OK, here is the problem, I have a running application on the server, and a developing version. User have more and more request and suggestion about the site. So, we need to upgrade the site and the database. Since the database update, we need some database schema change. How can we handle this? Because if the php program, we can easy as upload all the script files and deploy, but the database, it there any 'diff' for the database? Thank you.

I usually log every change I make to the database structure while I develop. Later I just apply the same changes to production.

You can always use migrations, kinda like rails

Related

Deploy updates for code igniter web application

I have a web application written on Code Igniter and almost ready for the release.
I'm looking into ways to do "automatic" updates for the clients.
Now there are going to be versions of the application on which the users will choose to update and when to do it.
I'm curious on how to update the files for the user.
What i used to do before using a framework i used to make a zip file of the new-edited files store it on an FTP and on the user side when he updated i just unziped the file and replace the ones on his side.
For the database schema and other updates i intend to keep a file with the required queries and run during the update.
Should i go with that way or is there something other that i can implement on Code Igniter?
A more straight forward road?
Also i'm still figuring out the part where a user will have to update from say version 1.0.0 to 1.0.3 (2 or 3 versions apart) and the requirements on the files side but on the database also.
Thank you
If you are willing to put it under version control with Git, you can use PHPloy to push only the latest change to the server through FTP. Check it out on Github: https://github.com/banago/PHPloy
Disclaimer: I've written PHPloy

Make a CodeIgniter app use MySQL replication the right way

I have a really nasty problem with a CodeIgniter application which I want to load balance using also MySQL replication.
In other PHP frameworks this would be a 5minute job because you may switch the datasource just before saving the data (CakePHP allows this, for example), but it seems in CodeIgniter that's a different story.
My problem is the application is legacy and I have to load balance it so I have all the hardware setup already done, the filesystem is in sync, the database has a slave and updates it as it should, but I have to make the second CodeIgniter application to read from the slave and write to the master.
I already found a solution but since the application is legacy I wouldn't want to go into its internals because I could destroy something that already works (it's also pretty sensible because people are paying within the app and it's also live which makes things even worse).
The solution I've found is this one which makes you change all the models in the application.
As further information CodeIgniter database driver (CI_DB_mysql_driver in this case) doesn't have any method for switching the connection or something.
Do you have another suggestion for tackling this problem? (besides changing all the models which I find a bit too intrusive)

Wordpress site release management strategy

I'm updating an existing wordpress site making significant modifications the the theme and site structure, as well as making updates to plugins which in turn store their data into mysql database.
As far as I'm aware there are 2 (3?) possible strategies here:
'Dump-and-load' MySQL database from DEV to LIVE and replace wp-content folder with latest updates.
Import changes via WP-importer and replace wp-content folder with latest updates.
Make database changes manually via WP admin interface and replace wp-content folder with latest updates (this is useful only for minor changes).
While I am developing in my own separate environment this is for an existing website which is currently live and will continue to receive updates from the public such as comments and entries into contact forms, hence I expect the database to be different now from when I release my changes.
Given this the options above provide the following problems.
1. DUMP AND LOAD
The 'dump-and-load' strategy seems to be out of the question as my data is being updated behind the scenes (this would have been my preferred approach as this is easily rolled back).
Result: requires synchronising databases post release to get latest updates, TOO COMPLICATED.
2. USE THE IMPORTER
Using the WP-Importer plugin page and post IDs will get updated, screwing up styling that relies on the post IDs to get activated. This in turn creates a CSS nightmare that I wish to avoid, having to go though the CSS after release to update the new page/post IDs with the ones the database created.
Result: Too finicky, not very professional approach leading to long and complex release process.
3. UPDATE DATABASE MANUALLY
This option is great for small changes but when for more complex releases the list of steps to follow on the PROD interface becomes long and hard to follow, making it easy to make mistakes.
Result: Too easy to screw up, only a last resort.
IS THERE A STANDARD WORDPRESS RELEASE STRATEGY FOR EXISTING WEBSITES?
So basically, my question is: What release process do other wordpress developers follow when UPDATING an existing website? Is there an option that I have not listed below that minimizes hassle and reduces time and complexity during release?
I've set up source control for the site using GIT and I am used to automating things via ANT or similar release script, this may be overkill for the current project but would be ideal to at least know of a simple way to update a wordpress site and minimize the chances of screwing it up.
Thanks!
I don't think this is particular to WordPress, it's a similar situation to any custom site. I personally favor replaying the SQL changes on production that were made on dev. The tricky part is that you have to know what SQL changes were made. For example a certain plugin may make some schema changes when you install it - you need to know what they were. You can do that by creating an export of your DB as SQL before installing a plugin, then take another export after and do a diff on the files.
Since you say you're making the modifications then I might assume you know what SQL changes you are going to make? Just make sure all changes you make to the DB are in the form of SQL script files and not just editing using the GUI (you can use the GUI to help write the queries, but save the actual SQL). After all of your changes are done you should have a bunch of SQL scripts that you ran during your development process - you can re-run them in order without encountering errors.
Then when it's time to push to production, create a staging version of production (that is take a fairly current DB backup of production). Run your update scripts on that and test that everything is ok. If it is, then you can run on production.
definitely make a backup of production before running any changes on it!
The guy behind WordFence was working on a deployment plugin called
Deploymint.
There's a new one called WP Stack.
Metal Toad Media discussed using Capistrano, but that Capistrano isn't specific to WP.
CrowdFavorite launched a service called
RAMP.
Needless to say, you have some other options. If you're making db changes manually make sure you're working with the serialized data effectively. I recommend using Search and Replace DB. WordPress also had a great little trick for changing the site url entirely from the wp-config file.
I assume you have everything running in a test environment. I would then:
Create a new database in your live environment.
Preload it with all content and configurations for the new site.
In your test environment, configure your config.php to point to the new database.
Upload all files to the live server. Upload your config.php last.
This will minimize downtime.

PHP Database Deployment git/capistrano

I'm working for a company which is using PHP. There are different CMS Systems being used like Wordpress or Magento.
We are working with git having our own repository server and we have to deploy to different servers our different customers.
I've set up a deploymentscript using capistrano which works fine but the Database Synchronisation is quite tricky.
Imagine the live-database contains user data and I have to create some new features after the site already launched and there are loads of sql data within the database already. I personally work with a dummy database since I don't need any customer information.
How are you PHP geeks are deploying your databases? I don't want to change the contents but only migrate new or modified tables. I'm looking for a complete deployment solution for that. I'm also open for other options besides capistrano if needed. Especially with Magento I had serious problems to keep my database sync..
Any help is appreciated.
Recently I have discovered this project: http://dbv.vizuina.com/, but I don't have used it, otherwise Symfony has a similar feature called migrations and it works very well.

Managing Joomla Website

Currently my workflow is like this:
Make some changes to the local
copy of my website
Use Akeeba backup to make a copy of my website and database
Delete contents of hosted server
Upload Akeeba backup files
Visit website and
run akeeba restore which syncs my
database
Is there a better way to manage a joomla website? The problem is, I have a team working on one website so this doesn't really work as well. Setting up version control with the server won't exactly work because pretty much everything in Joomla gets stored in a database so we would need to somehow also get the CVS to work with the database. Potentially if Joomla and SQLite worked together (they don't) a CVS solution might work.
Write a php script, doesn't look like you are doing anything to difficult.
The only problem I see with your process is the downtime. In order to eliminate the downtime you can create two versions of Joomla on your LIVE server and point the apache to one of them, when you deploy your code, do it to the currently "off-line" version of Joomla and after you finish the deploy - point the apache to that version. Just a thought ;)

Categories