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
Related
this is my first time to publish my application using CodeIgniter.
I used to push applications using SpringBoot or Scala to GitHub. At that time there were only files which I developed, and library dependencies ware written in build.gradle and build.sbt.
At this time, I am using CodeIgniter and there are a lot of files that have nothing to do with my application. Should I erase such files or publish my application without doing anything?? Or, is there something to do before pushing it to GitHub??
What you you mean with "files that have nothing to to with my application"? Is it the codeigniter framework itself. I would personally commit all those, because you will need them again to ever restore your framework back its previous state.
If you mean external libraries such as those installed via composer or bower or something similar, I would leave those out of the repository. The libraries can always be re-installed from source later. And what's more, if external libraries are updated you don't want to have to keep updating your repository every time and fill it with unnecessary commits.
If you mean CodeIgniter's working cache, absolutely leave it out. These files will cause you problems if you ever pull your repository again, and they change constantly anyway.
Scenario:
My team manages multiple Joomla websites for our clients. While we manage the development/hosting of the sites, the clients do all of the content updates (creating articles, content, uploading images etc...)
We run these websites in the following standard configuration where we have
A development server
A staging server
A production server
The client makes all of the content updates to the production server (on a daily basis). The other two servers are used primarily for new development and testing.
We currently are using, BitBucket as our SVN for these websites (we are just starting out with this). Currently all files pertaining to the website are stored in the repo.
The Problem
Based on our current setup, if a developer makes changes to the dev environment, and that change set is then pushed to the production environment, we end up overwriting all of the content updates that our clients have made in the production environment.
My Question
How do we successfully utilize a source control system, and maintain the flexibility to allow our clients to continue to make updates directly on the production server, without forcing them to make content changes on dev, staging, and then production?
While you briefly described your workflow, there are some things to be considered. There is no general rule, but look into the following suggestions:
Put into version control JUST the extensions you have developed (template, components, plugins etc.). The customizations are anyway the only things you add to Joomla. Hopefully no core hacks. Alternatively if you really want to version the whole installation, you should at least ignore media folders that are changed by the clients / you. I see no need to put the whole Joomla site under version control.
I imagine your clients are not actually changing PHP scripts, just media files and database entries. You should only push to production code and / or database schema changes.
If you are relying on a commit - push to FTP feature, or manually pushing files, I would suggest looking into building a distributable version of your changes, in a form of a package that can be deployed via the Extension manager. Building packages can be done in one click with a tool like Phing. For example if you make some changes to the template, create a new template version, create the package and update first the staging server / testing server and if all goes well, the production.
Some things shouldn't be in version control.
In general, source code should be versioned and data should not. I'm not familiar with Joomla, but any kind of "uploaded content" directory should be in the ignore file for your version control system. That way you can deploy changes to the software without worrying about overwriting data.
Of course, your data should be backed up regularly, but that's not what revision control is for.
If you have
a staging server where you test the website changes (layout, new functionality, new css)
a production server where the user publishes new content
you need partial database updates along with file synchronization.
The database is pretty hard as the assets table may be affected both by configuration changes on the staging server and by new content on the production server; for this and any other shared tables, we address the issue by making sure the ids don't conflict right after the update leaving a sufficient gap.
Although - to quote most other answers - revision control is not for data nor for the database, it is indeed very nice, especially with pre and post-commit hooks to perform the required database actions; however, any scripting/publishing tools going from rsync-rdiff to phing to ant - maven will do
We have developed a CMS based website builder. It is currently available only in asp/ms-sql. A php/mysql version is in production now.
One critical thing that we are missing is a way to notify users of this software about an available update and a simple "one-click" solution to installing the update.
The update could be something as simple as correcting a typo or as complex as adding a new feature which would entail new pages in the CMS, changes to the public pages and changes to an existing DB table or the addition of a new table.
The question proposed is... Where do we even begin to find information regarding the implementation of an update?
Hope someone here can point us in the right direction.
When an administrator logs in, the site sends a HTTP request (using CURL from the server, or JSONP from within the browser) to the update server with it's current version. The update server replies with 'there is a newer version: 2.0.1.1.2' or 'no update available'.
On hitting update, replace core files and adjust the database by ALTER TABLE statements.
Ensure you have the file permissions to write em with the www user.
You should build the software a way that you have files which do not get edited by the user and files with only user content. So you can replace the core files without worrying to replace any user content. User config files need special treatment.
It's not that hard so I hope my suggestion helps.
Just make sure you have a very strict API and code, so it works for all customers, no regard of operating system and environment, it's difficult to change things later.
I also suggest using SSL for the communication.
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.
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 ;)