Testing yesterday's data with tomorrow's code

Pre-Dogfood Server


To check tomorrow's code (trunk) with yesterday's data, you can access the links below. Most of the year, these sites are running trunk, but during the release process, we run the upcoming version. Ex.: branches/9.x is used instead of trunk until dev.tiki.org moves from 8.x to 9.x

http://trunkdev.tiki.org/(external link)
u: trunk
p: trunk

http://trunkdoc.tiki.org/(external link)
u: trunk
p: trunk

Requested for the future:
http://trunk.tiki.org/(external link)
u: trunk
p: trunk

http://trunkinfo.tiki.org/(external link)
u: trunk
p: trunk

http://trunkthemes.tiki.org/(external link)
u: trunk
p: trunk

http://trunktv.tiki.org/(external link)
u: trunk
p: trunk

http://trunkprofiles.tiki.org/(external link)
u: trunk
p: trunk



Inversely, if you want to see how Tiki 6.x was: http://legacydev.tiki.org/(external link)

Challenges

  • Dogfooding Tiki on our own sites is great to find bugs, but it makes it difficult to work.
  • Say I find a bug on a tiki.org site, is it fixed in the next version, or should I report/try to fix bug?
    • This is very time consuming.
  • Detecting and fixing bugs is much less efficient without real data. We would like to give developers access to a site where they can test a fix, before committing (or very quickly after)
  • The Quality Team is supposed to check that a commit works in trunk, before accepting in the stable branch. How to do this efficiently without data?

Which is why we have set up a continuous Pre-Dogfood Server. Yesterday's data with tomorrow's code (code in trunk). Ideally, this would be part of TRIM so everyone in the community could easily set this up for themselves, but it's not at this stage.

Setup system for permanent testing of trunk with real data

1- Run a new site ex.: trunkdev.tiki.org
    • On a server we can give trusted devs access to test
    • With backup of real data from dev.tiki.org
    • Using trunk
2- Daily update of code (from trunk)
3- Daily refresh of data (from live site)

Modifications

  • Use .htaccess password to make sure robots don't index the site

Benefits

  • Upgrade procedure is tested very frequently
  • Makes it very easy to compare old & new interfaces (and people can say what they liked/want to keep about the old one)
  • Make it easier for Tiki community to make a judgment on when to start dogfooding next version on community site.

Potential users

  • All devs: To test before an upgrade. Ex.: They could load test daily and report any feature or performance regressions.


Ideas to improve


Related


alias


Contributors to this page: marclaporte44401 points  , changi67180 points  , Jyhem2569 points  and alain_desilets522 points  .
Page last modified on Monday 07 May 2012 14:40:44 CEST by marclaporte44401 points .

Switch Language

Subscribe to Tiki Newsletters!

Delivered fresh to your email inbox!
Newsletter subscribe icon
Don't miss major announcements and other news!
Contribute to Tiki

Shoutbox

Torsten2431 points , 14:06 CEST, Sun 22 Apr. 2012: Next Webinar at Thursday, 17th of May 2012 (21:00 UTC)at http://tiki.org/live
Torsten2431 points , 11:43 CEST, Tue 10 Apr. 2012: Next Webinar at Thursday, 19th of April 2012 (21:00 UTC) at http://tiki.org/live
Jyhem2569 points , 13:07 CET, Fri 16 Mar. 2012: What happened to the BBB room ?
Torsten2431 points , 01:44 CET, Sat 25 Feb. 2012: Next Webinar at Thursday, 15th of March 2012 (21:00 UTC) at http://tiki.org/live
Torsten2431 points , 13:29 CET, Fri 10 Feb. 2012: Next webinar at Thursday, 16. of Feb. 2012 (21:00 UTC) at http://tiki.org/live