I'm looking for inputs into how I can manage the upgrade process itself of a homegrown php/mysql application. Meaning, if we have a 'stable' version of our php/mysql application working on our production server, and we now want to upgrade it to the next version that we've worked on - how do we go about doing that elegantly? What practices should I be implementing?
What I was planning to do was just to
Ask the developers to stop
checking in code after all stability
/ functionality tests are done
Take the application offline*** (Q: how should I prevent ppl for logging in / accessing public pages? Best practices for that?) but allow access to developers through a secret login page / url
Log onto the production server and check out the latest version
locally***
Have the developers/testers test their code through the secret access page / url***
After that is done, we restore access to all by removing this secret access page / url, removing the site-under-maintenance page and restoring access to all.
***NOTE: A simple way of doing this would be to rename /myapp/ to /myapp.old/ and put the new application version into /myapp.new/ Developers would access /myapp.new/, test to their satisfaction and then after we're done, we would rename this back to /myapp/ (this is just the basic idea)
This is a huge question, and in many ways it will depend on your specific project. But here are some practices to think about:
Put lots of comments in your code. Things that seem perfectly logical now will be confusing when you go back to make changes in a year or two.
Maintain a development version of the site with its own database. You can test changes to the site before publishing to your production site.
Use a PHP framework (such as CakePHP, CodeIgniter, etc). If you are far along on your project, this may be difficult to do. But it will help you write code in a way that is easy to update, and will include a lot of stable, mature functions that you won't have to write from scratch. Using one of these frameworks (and following its best practices) is probably the best way for a beginner to learn to think about writing modular code that's easy to update. This will also encourage you to develop your database in a way that is consistent with the structure of your site.
Write tests (the framework should help you with this) to programatically check your code for errors.
Use a version control system such as Subversion or Git. This allows you to track changes to the site, and easily roll back changes if/when you realize they are buggy.
Comprehensive unit test coverage would be very helpful, as would small, highly cohesive, low-coupled classes. In addition to the unit tests, good coverage from an integration level would be valuable.
Related
Here's the thing. I love Ruby and I've been using it for the past couple of years. I love everything about the language and the community.
But I have this soon-to-be-large WordPress site, where I have to implement a lot of additional functinality. The problem is, I really hate customizing WordPress beyond simple theme design.
Examples of things I need to do:
add some additional information to profiles, like karma/points/reputation system
offer users to create their own page after they're allowed to do it
pulling data from some external API and displaying it on the user's profile
I got really used to the whole agile BDD workflow, where I go from Cucumber features to RSpec to implementing the stuff, and the whole WordPress architecture looks to me like ok I'm just gonna have to pray this works.
I'm not sure if it's even wise to try to write some part of the app in Ruby and try to make it work together with WordPress, or if I should just take WordPress as the only thing I've got and make the most of it's strenghts and weaknesses.
The main issue for me is that everything I'm going to write in PHP will take about 5 times as long than if I do it in Ruby, and it will probably also be more secure and robust, since I don't have as much experience with complex PHP stuff. I mean I've done a lot of PHP in the past, but I always felt like the whole thing is going to fall apart at one point.
I know there is probably no definite answer on how to approach this, but any suggestions are welcome.
We've integrated a Rails app into a TYPO3 installation. It worked out pretty well. The key point is to use Rails' support for adapting models to tables of a legacy app. An important point is to handle authentication which we handle by passing the TYPO3 session key to the Rails app in a hidden way (using PHP as the web-client and passing appropriate headers) and looking it up in the session table (respecting the session timeouts). The Rails app itself is mapped into a sub directory using passenger. Performance is very good, it's even amazing compared to our previous implementation trying to use Extbase.
So, in conclusion: If you do it right and the interfaces between the two apps are well planned such an approach can offer great benefits and the best of two worlds. If not done right or you don't understand some implications of Wordpress (like security) you will create a big mess prone to security breaches.
BTW: We reached feature parity with the Extbase (MVC framework in TYPO3) solution after 4 days of using Rails. The Extbase solution took 6 weeeks and caused a lot of headache and trouble. So your time factor may be even better than 5:1.
Why not learn how to to Behavior Driven Development in PHP for WordPress? In fact, this is one of the great opportunities for developers in 2017. We now how full blown BDD frameworks in WP-Codeception, so that you can even automate Gherkin feature files, just like in Cucumber. Check out WordPress-BDD.com for some usefull info.
I'm thinking about rebuilding my website from scratch, but this time, using a CMS. Everywhere I turn people tell me to use a cms, but it's only now I'm really considering it. My site isn't too complicated. Is this a good idea in terms of workflow? I'm the only person who will edit the site, so if it's just a matter of workflow and efficiency, should I just convert now before it gets really big?
Sure, a few come to mind.
Deployment complexity. Many CMSes require a database, which means running a database process somewhere, and backing that up, as well as the rest of the code and assets for the site.
More space will be required to hold the CMS code for the manager, framework, libraries, etc.
Bloat could come into play, the CMS may, and likely would, implement features you have no use for.
Additionally any CMS will have some kind of limitations, some things will be more tricky to do than others when compared to a mostly static site.
Just read the code. That's often all the arguments you need. (If your needs are really simple and you don't need plugins and you don't need to write any code yourself I'd still use a CMS, though)
If your site is mainly a design showcase, and doesn't have real content in it, then a CMS will only get in your way and make things harder.
Otherwise, it will mostly be of help.
Along with everyone else's statements. If it's just a small site you don't necessarily need a CMS, but if you are wanting to use a CMS for client projects in the future, why not start now.
Deployment. If you're doing some big changes to your site or testing something, you'll probably want to try it out locally with a development copy of the database. Once you're done, how do you get everything to the live site without overwriting, say, comments that were made on the live site since you created a development copy?
Specialization. CMS's are great for some things, but they're bad at others. What if you want to add more complex functionality to your site? It might be a plugin or module at first, but soon you're writing all this code and you realize you should have just used a framework and built the CMS part yourself.
If it's a simple static site with a single editor and without any aspirations of using complicated functionality and you feel confident enough in your web language of choice, then go for it. Even if you don't feel confident enough, it should be a good challenge.
Write some minor templating so that you can separate your code from your design, have some simple way of adding articles or blog posts or whatever - it could be as simple as including text files from a directory.
Using a CMS, even in their modern and quite usable state will require more resources, hardware-wise. and will probably have a steep learning curve. It will also require maintenance and dilligent security patch application as new vulnerabilities appear. On the other hand a CMS can get you up and running with a basic site quickly, and grow with your needs if you feel like enriching it, as you get to use its large variety of ready made plugins and extensions. You want blog comments with users logging in via OAuth? No problem. RSS? There's an extension for that.
Bottom line is, if this is a simple static site with a single editor as you describe it, it should be trivial to set up some code to run it. You'll spend as much time on its template design as you would on customizing a CMS's template, avoid the initial learning curve a CMS requires, and not worry too much about the resources and maintenance a modern CMS requires. You will, however, be limited in functionality and future ideas by what you can write or integrate yourself.
It depends somewhat on the purpose of the site.
If it is a means to an end of getting information posted on the web, then adopting something like WordPress will quickly get you going, and provide lots of extra functionality that would take a fair amount of time to build in - e.g. stats, feeds, remote publishing etc. There are a few basic steps you'll need to go through setting up self-hosting on a shared web-hosting package e.g. creating the DB and unzipping the files etc but fairly straightforward really. And the time you save administering your website can be focussed on other things where you're making a difference or doing something different to everyone else.
However if your purpose is in part the learning experience of developing the functionality or you have unusual requirements that aren't in a standard CMS, then there is an argument for developing your own.
This is more or less related to project management and also with every developer. How you guys handle this situation when you have developed many features on development site and all are tested by client and ready to go live.
These features have some code in common files ie. One PHP file have the code for one feature as well as one other feature.
But client will ask you to upload only 2 feature out of 10 or 15. Files are common if you upload that file directly will leads to error problems because they have code for other features. If you upload all updated files then all feature will be live.
A possible way is go back and comment out that feature which is not needed live for now from common files. But there is possiblities to forgot to comment anywhere else.
This is also not a good way and at last client will say what happen everything was tested on development server and why these bugs and errors are introduced on live server.
This will reduce the faith on developers.
I faced this problem many times and could not found any good way to avoid these issues. So I am thinking that you guys also facing or faced this problem.
I am thinking versioning system can help here.
How you guys are handling this?
Could you share ideas?
The situation you are describing is impossible to manage sanely. I don't believe it would be possible to make this situation work, but the real question is why would you want to?
There are a number of issues with the scenario you describe, but the core issue is really this. You are testing one thing, and deploying another. You acknowledge in your question the interconnected nature of changes. In reality it is even more difficult than you describe. You simply cannot know how a system will behave when you try and deploy parts of a tested solution. Why test it at all?
The only sensible solution I can see is to have a sandbox environment where new features are demonstrated. However keep your test enviornment only for testing stuff that will go live. So in your example the one or two features are in test, ready to be signed off for prod, and the other featues are locked in the sandbox.
This leads to the next problem, which is managing your source code. I don't see any sane strategy for managing the arbirtrary inclusion of features from a code base. Even under the mostflexible system I know, Perforce, any branching straegy would require awful resolves on merges as you try to move stuff in and out.
I have seen this happen, and believe me it gets very ugly.
I suggest you come up with a better solution. Talk to your client and change the way things are done. It will be better for you, and in the long run better for them.
A solution could be to use cheap version branching as provided by VCS such as Git or Mercurial. The project would consist in many feature branches used to develop said features and build branches where feature branches would be merged and adhoc fixing would take place. When a build branch is ready for test, it is tested, fixed if needed and then the build branch is shipped to production platform.
When features have been validated, the build branch can be merged into remaining feature branches so the branches under development can integrate the "official" changes.
To sum up, the application is custom built from existing feature branches as needed.
One reasonably sane way to manage this on the code level is to isolate each feature into a plugin. Then you can add/remove features on-demand by simply enabling or disabling corresponding plugins.
But this solution has certain costs:
Time to develop and test plugin engine for your app
You need to test every plugin configuration (set of enabled plugins and their versions) that is going to be deployed. Otherwise there's a risk that this specific set is not compatible and end users would be first to see resulting crash, or data loss, or some other horror
Additional time to wirte plugins the way that they're minimally dependent on each other.
It's usually worth it only if you have many clients with different needs. In your case, I'd recommend explaining cost of separately enabling features to your client to see if they really need it this hard. Most likely, they don't
I have developed an application and now I would like to hire some programmers to work on several pieces of it to upgrade and tweak it.
I have read other questions/answers here but they are mainly about obfuscating the code which is something I do not want to do (as I need them to read it and tweak it).
What I'm basically asking is, what is the best way to structure my code so I will have to expose only what I have to?
A good example for me is a webapp called RightNow which I'm developing for at work, what they do is they let you play around with all the widgets (you can create/edit/remove any widget) but the core of the application is in folders I do not have permissions to.
After you do your coding on the widgets, you then 'deploy' the application and it goes live. I have no idea what the deployment actually does behind the scenes, but this is one practice (not sure if it's the best) which allows the application owner to have control over the core of the code but still allow development for it.
Is there a better way? what do you think?
First you can use a version control software like SVN for example.
and then you can have copies of the code, one for testing and one for the your programmer. When the programmer is done changes and tweaks, the testing code gets updated first and when the test are done the live application gets updated.
you can obfuscate your core classes(ones that you don't want to expose). and other developers can include and use them at the same project as long as you provide a nice api to your classes.
I've used Wordpress and Joomla to build a couple of small websites, and done some hacking about to get them running exactly as I want. But both of these, and probably many other PHP CMSs, are subject to a constant barrage of security fixes. I don't have to time to test the fixes, make sure my customizations are still working, and roll them out before anyone attacks the site, then do the same thing again a month later - I'll never get anything else done with that kind of overhead.
So my question is: Is there a (preferably PHP) content management system that somehow successfully avoids the constant barrage of security updates and resulting testing/sysadmin work? So I can just work on it when I have time, not keep racing to patch the latest attacks?
Bonus points for having a sane plugin model to make it easier to code against. More bonus points if it provides an easy method to import data from Joomla and/or wordpress.
Thanks
EDIT: As rightly pointed out, avoiding updates entirely is not a sensible goal. Rather, I want to minimize the pain of updates. So what I'm really looking for is:
Easy to adapt and theme in a way that is guaranteed not break during updates
Simple update process
there is no cms (no software, for that matter) so secure you never have to update. developers make mistakes, and new exploits appear. so every cms should be "subject to a constant barrage of security fixes". if it is not, you should ask yourself about the security policy of the project and the security of your site. see The Open Security Model, Drupal and ExpressionEngine on Security for a related read.
so unless you don't care about the security of your site, you are asking the wrong question. i think it should actually be: is there a cms that is customizable without modifying core files so that security updates don't break my customizations? or: how can i customize a cms so that security updates don't break my customizations? security updates usually don't break a (even customized) site - unless the customizations are done the wrong way.
my answer to that new question would be Drupal (including bonus points).
The last versions of WordPress (2.7 branch) have auto update for core and plugins making it really easy to upgrade when a fix is available. The api is also awesome - I've done quite a few WordPress based sites and rarely (if at all) needed to hack the core.
As long as you customize through plugins or themes, and use auto update when a new version is available, you shouldn't have any problem at all.
I like CMS Made Simple, which is written in PHP.
In term of security, stability & flexible maintenance I suggest Symfony framework
(see:http://www.symfony-project.org/). It has a lot of plugins, support towards wordpress, joomla and whatever you need.
See also PHPcake at http://cakephp.org
I really like ExpressionEngine, made by EllisLab, its based on their open source framework CodeIgniter, (which I think is one of the best PHP MVC frameworks).
There is a free version of ExpressionEngine for non-commercial use, which is all I've used, but the paid addons + modules look pretty slick.
As for actually really free, ModX is alright, but has a frankly wierd plugin system, that said, Ive built a couple of sites on it, and been happy with the results.