Loading...
 
Skip to main content

Custom Share Module 0.1dev

History: Pre-Dogfood Server

Preview of version: 53

Managed by the Infrastructure Team, Testing Team and Wishlist Team

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://nextdev.tiki.org/ (updated 4 times per day)
u: next
p: next

http://nextdoc.tiki.org/ (updated 4 times per day)
u: next
p: next

http://nextinfo.tiki.org/ (updated 4 times per day)
u: next
p: next

http://nextthemes.tiki.org/ (updated 4 times per day)
u: next
p: next

http://nexttv.tiki.org/ (updated 4 times per day)
u: next
p: next

http://nextprofiles.tiki.org/ (updated 4 times per day)
u: next
p: next

http://next.tiki.org/ This is for tiki.org The cron job for next.tw.o is executed at noon and midnight my time (-6h to get NY time and -9h to get SF time)
u: next
p: next

http://nextparserdev.tiki.org/ This is for the new Jison Parser (updated 4 times per day)
You need to clear all cache so the Jison Parser kicks in.
u: next
p: next



Inversely, if you want to see how Tiki 6.x was: http://legacydev.tiki.org/
Inversely, if you want to see how Tiki 8.x was:

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.: nextdev.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

  • all pre-dogfood servers should indicate in how many hours is next data refresh
  • To make *.tiki.org upgrades easier, to catch regressions sooner, dev.tiki.org could run on monthly updates of trunk code, while nextdev.tiki.org is daily trunk. Before each monthly upgrade, nextdev.tiki.org is checked to catch and fix regressions.
  • Change the domain name from trunk to next, because it's not always trunk, but always next done
  • Tracker item: #4200 - - Compare generated HTML for all *.tiki.org sites between versions (to check for regressions/changes of behavior)
  • Handle _htaccess
    • Use unix file link from .htaccess to _htaccess
  • Clear all cache Now part of the shell installer
  • Apply a profile or a System Configuration
    • To add a header "This is a test site, all modifications will be overriden"
    • User_watches = n (Testing changes shouldn't spam people)
    • A way to set robots to avoid indexing the site completely
  • A way to receive alerts on major breaking
    • SQL error, PHP error
    • Would need a crawler for early detection of breakage
  • To do the same thing, but for various profiles.

Related

alias

History

Advanced
Information Version
Marc Laporte 76
View
Marc Laporte 75
View
Marc Laporte 74
View
Marc Laporte Code Plugin modified by editor. 73
View
Marc Laporte memcache_enabled 72
View
Marc Laporte Code Plugin modified by editor. 71
View
Marc Laporte Code Plugin modified by editor. 70
View
Marc Laporte 69
View
Marc Laporte Code Plugin modified by editor. 68
View
Marc Laporte Code Plugin modified by editor. 67
View
Marc Laporte 66
View
Marc Laporte Code Plugin modified by editor. 65
View
Marc Laporte Code Plugin modified by editor. 64
View
Marc Laporte Code Plugin modified by editor. 63
View
Marc Laporte Code Plugin modified by editor. 62
View
Marc Laporte Code Plugin modified by editor. 61
View
Marc Laporte Document a reference System Configuration for Pre-dogfood servers 60
View
Marc Laporte 59
View
Marc Laporte 58
View
Marc Laporte 57
View
Marc Laporte 56
View
Marc Laporte those old legacy sites are gone now 55
View
Marc Laporte 54
View
Marc Laporte 53
View
Oliver Hertel 52
View