Jump to content

Invision Community Blog


Managing successful online communities

bfarber
 Share


Some development decisions made prior to 4.0

Development is much more than just opening a text editor and writing some code. This is how most developers start, of course, and may be what an individual developer's day to day duties entail at a large corporation, however when viewing the "big picture" there are many other decisions that must be made in the course of building a software package for release that clients often don't realize were even considered. We thought you might be interested in hearing about some of those decisions that were made regarding 4.0, prior to ever writing a single line of code.


Minimum Supported Versions
One decision that has to be made relatively early in the development process is what dependencies will the software require. For software developed in PHP, this typically means what version of PHP will be the minimum, and (often) what will be the minimum required version of MySQL.

PHP 5.3.0 was released in June of 2009, and includes functionality that we intend to utilize within the 4.0 Suite. Subsequently, this was an easy decision to make.

We were leaning towards requiring MySQL 5.5, which was also released in 2009. We feel that 3 years is long enough on the web to incorporate updated software within most hosting environments. Upon investigating the functionality we intend to utilize in MySQL, however, we have determined that MySQL 5.0.3 and above includes everything we need, so MySQL 5.0.3 will be our minimum required version.


Profiling and Benchmarking
If you are a PHP developer and have ever attempted to profile your code, you probably realize it can be challenging. Many IDEs support some level of profiling built in, however it is almost always manually invoked. xdebug is a powerful tool for profiling, but again it requires you to enable profiling, run a request, and then view the results. In a live environment this is nearly impossible as profiling adds a lot of overhead to page loads and creates hundreds of profiling files quickly.

Our goal is to be able to profile changes as they are committed, right away. We have decided to install Zend Server to the server that will host our staging environment for 4.0, which supports automatic rule-based built in profiling. This will allow us to easily profile requests automatically, even those that we may not "know" how to trigger manually (e.g. a specific task in a specific circumstance takes a long time to execute).


Improving automatic deployments
While automatically building and deploying the software to our staging environment itself is not a challenge per-se, a lot of times changes occur that require some sort of manual intervention to enact. We may have exported updated skin templates, language files, or there may be SQL queries that need to be run. We are developing an automatic deployment routine that can handle all of this easily and programatically, ensuring our staging environment is truly always up to date with the latest changes.


Website and forum organization
Not directly related to 4.0, another area we had to consider was our organization on the website and on our community here. This extend to all areas of the community, from the organization of our feedback and support forums, to our marketplace categorization, to our bug tracker categorization. The approach with 4.0 will be that we have one suite with modular applications that can be enabled. We need to market the software this way, and we need to ensure that the logical work flow for our clients reflects how our suite is designed. You will be seeing changes to categorization throughout our sites based on 4.0 in due course as a result.


Loose ends
And beyond all of the stuff directly related to 4.0, we felt it prudent to tackle a lot of loose ends before we jumped into a major overhaul of our entire software line up. There were a lot of smaller tasks that have been pushed off for a while but which we've finally sorted through which we feel will afford us less distractions as we work on the next release. Most of these tasks were minor, but not unimportant. Examples include:

  • Moving our documentation to the main website
  • Improving minor areas of IP.Downloads and IP.Nexus to allow clients to better help themselves, or to allow a smoother work flow within the administration areas our employees utilize every day
  • Scripts on our end that allow us to better manage certain services
  • Cleaning up old content in our installation, such as removing unused IP.Content blocks and deleting left over files on our server


None of this directly affects 4.0, however the less distracted we get with minor tasks during 4.0 development, the better we can focus and deliver the product in a timely manner and with less chance of distraction-related bugs.


Of course hundreds of other decisions have gone into 4.0 as well, some of which we will talk about in future blog entries. We thought you might be interested in hearing about some of the smaller things us developers do here at IPS, however, besides developing great software products to power your communities!
 Share

Comments

Recommended Comments



Cleaning up old content in our installation, such as removing unused IP.Content blocks and deleting left over files on our server

 

You could just have it pulling changes in a version control system and all of that would for sure be handled automatically? Better than having to do it manually ;)

 

We have our servers use git and upon deploy all changes are pulled. (Although I don't know the exact details on our deploy script)

 

I recently did a similar thing. I removed a lot of outdated IPB 3.0 and 3.1 files from our git repo and then deployed the changes -> the deleted files then gone from all our application servers.

 

Since your using a stock version of IPB(?), I guess it would "just" be a matter of retrieving the latest version from your version control system? 

Link to comment
Share on other sites

excellent article - even though I don't fully grok the PHP/MySQL world of programming I can totally appreciate the effort that goes into it. And it shares identical correlations to any other software development endeavors.

 

What I come to appreciate more and more with IPS. And the attitude to embrace the challenge of change, for the better of it's customers - and by extension our members and customers. 

 

keep up the fine work!

Link to comment
Share on other sites

TSP - we do build via SVN deployment to our site, but over the years some files get left over and there were a bunch of files from before we started deploying from SVN.

 

SVN? Git with the times, man.

 

I'll show myself out...

Link to comment
Share on other sites

regarding point "Improving automatic deployments"

 

I think this only affects your staging enviornment, but I'd like the chance to say again => please rethink the automated upgrade mechanism you put into production shorty.... updating the board version via website click

 

this does only work for the licensed production envrionment and does NOT work for local or other test-installations (like I'm running my own staging environment and I do upgrade this EVERY time before upgrading production and I've found quite a few side-effects which would be a BIG problem in production)

 

so please work on that upgrade mechanism, to enable this on staging enironments on customer side - as this is included in the license (one non productive installation)

 

thanks in advance

Link to comment
Share on other sites

ok I'll admit it, I saw Zend and initially thought CRAP I gotta install zend...then I finished the sentence :smile:

I am lucky... My servers are ready for this

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.3.0, Copyright © 1998-2010 Zend Technologies
    with the ionCube PHP Loader v4.2.2, Copyright © 2002-2012, by ionCube Ltd., and
    with Zend Guard Loader v3.3, Copyright © 1998-2010, by Zend Technologies

Link to comment
Share on other sites

  • Management

My question is regarding PHP requirement. Why not determine PHP 5.4 as minimal requirement and take full advantage of PHP improvements. PHP 5.3 will reach EOL soon

 

That may be true but we always have to go for a "lowest common denominator" and recognize many web hosts will not upgrade off 5.3 for quite a long time.

Link to comment
Share on other sites

Since your using a stock version of IPB(?), I guess it would "just" be a matter of retrieving the latest version from your version control system? 

 

Actually, there are parts of our website that aren't stock.  We have a lot of custom modules inside Nexus to handle things specific to us, and we have a lot of independent scripts on the server that do various things not related to our software, although that's irrelevant - all of that can still be put into an SVN repository.

 

We actually do have an SVN repo for our website that manages custom stuff which can deploy right to the server.  We still had a lot of old stuff to clean up though.

Link to comment
Share on other sites

Will the visual editor still be retained? I find it's the only way I can easily customize the skin. (I usually like to keep the default theme but alter the colors.)

 

I believe we will still see some sort of visual skin editor available with 4.0, however we can't guarantee that at this time.

Link to comment
Share on other sites

We develop, design and translate locally in team and try to upload changes through SVN. Our difficulties are:

- transfer changes in different skins (overwritten default skins)

- transfer translations (transfer only updates on the language made locally)

- transfer blocks for IP.Content (they must be setup in each installation manually, again and again).

 

I would appreciate if new solution will make development in team a bit easier considering folders and permissions. 

Link to comment
Share on other sites

- transfer blocks for IP.Content (they must be setup in each installation manually, again and again).

 

You can already export and import blocks in IP.Content.  Why would you manually set them up on each install?

Link to comment
Share on other sites

You can already export and import blocks in IP.Content.  Why would you manually set them up on each install?

Oh. You are just too quick in your development :D We must have here a version where there is no blocks import yet.

Link to comment
Share on other sites

I'd really like to see a way of being able to do upgrades in a command line environment, without the need to use the web based upgrade system. Being able to automate things like that would be so helpful because then I could do it all via SSH.

Link to comment
Share on other sites

I'd really like to see a way of being able to do upgrades in a command line environment, without the need to use the web based upgrade system. Being able to automate things like that would be so helpful because then I could do it all via SSH.

 

Seconded.

Link to comment
Share on other sites

I'd really like to see a way of being able to do upgrades in a command line environment, without the need to use the web based upgrade system. Being able to automate things like that would be so helpful because then I could do it all via SSH.

 

Thirded. :smile:

 

 

I understand why you choose PHP 5.3 as your lowest supported PHP version. 5.4 is already supported by cPanel, however, and it is only going to spread in the time you take to release IP.Suite 4.0. I just hope it doesn't hamper your development too much, as 5.4's new playthings are excellent. Any chance you might bump up your minimum required version at some point during the 4.0 lifecycle, or can we count on PHP 5.3 remaining the baseline until 5.x?

Link to comment
Share on other sites

Thirded. :smile:

 

 

I understand why you choose PHP 5.3 as your lowest supported PHP version. 5.4 is already supported by cPanel, however, and it is only going to spread in the time you take to release IP.Suite 4.0. I just hope it doesn't hamper your development too much, as 5.4's new playthings are excellent. Any chance you might bump up your minimum required version at some point during the 4.0 lifecycle, or can we count on PHP 5.3 remaining the baseline until 5.x?

 

PHP 5.4 doesn't add anything we felt necessary - traits was the only new language feature of any particular significance. I'd have liked to use some of the minor new features like function array dereferencing, $this in closures, class member access on instantiation and the binary number format (to make bitwise operations less confusing) - but none of these things are a hindrance to development at all.

 

Naturally, we support 5.3 and above so if you run 5.4, everything will work plus you'll still get all the performance improvements they made in 5.4.

 

We intend to keep 5.3 as the minimum required version for the foreseeable future.

Link to comment
Share on other sites

Hello!

 

Will 4.0 contain changes in more user friendly light interface without a lot of buttons, links, options, checkboxes etc? :) Also it is unclear why ckeditor in ipb still does not have an option to upload images directly to server as an option to URL?

Link to comment
Share on other sites




Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy

×