Loading...
Skip to main content
Navigation and related functionality and content
Features
Requirements
Download
Install
Backup
Upgrade
Help
FAQs
Need Assistance ? Join-us live this Thursday, click for info !
Related content
Find
History: TRIM use cases
View published page
Source of version: 5
(current)
^ The "Tiki Remote Instance Manager (TRIM)" will go into maintenance mode, and the code will be forked and revamped to become its replacement, now known as the "((Manager|Tiki Manager))". ^ !# TRIM use cases Documentation on how to use each TRIM command resides on the ((TRIM)) page. This page is to list current and future scenarios with general steps and some tips, and example use cases. {maketoc title=""} Note: For all automated (unattended) operations, there should be a warning email upon failure (disk full or SSH failure) !!# Create or take over a Tiki instance * -+make instance+- !!# Backup and restore !!!# Backups * -+make backup+- !!!# Automated backups * ((TRIM|#To_setup_automated_backups|Set cron job)) !!!# Restoring * -+make restore+- !!# Automated security checks * -+make watch+- !!# Updates and upgrades || __Updates__ | from x.x to x.y | Can be automated. If you are in a branch, to the tip of that branch. If you are in trunk, you get the latest trunk. __Upgrade__ | from x.x to z.z | Doesn't make sense to automate because after the 1st run, you are already at the target version.|| For all updates and upgrades, a maintenance page should be shown (because weird errors can occur when part of the code has been updated) !!!# Update * -+make backup+- (to be safe) * -+make update+- !!!# Upgrade * -+make backup+- (to be safe) * -+make upgrade+- !!!# Automated updates * like -+make update+- but with email alert of failure {REMARKSBOX(type=>"tip", title=>"Tip")}Makes sense to also set up automated backups{REMARKSBOX} !!# Cloning {REMARKSBOX(type=>"tip", title=>"Tip")}The difference with a backup: A backup provides you with an archive (.tar.bz2) of your whole instance, whereas a clone is a live usable instance.{REMARKSBOX} !!!# Manual cloning * -+make blank+- to create an instance to be cloned to * -+make clone+- and select from and to {REMARKSBOX(type="confirm" title="Use cases")} * Debugging * Moving Tiki to a new server * Keep a working copy before a major upgrade. Why? After the upgrade, it may happen that a user reports an issue, and indicates that current behavior is different than previous behavior. Has their been a regression in the code? A change of configuration? Is the user mistaken? This site will help the process. This site should restricted (ex.: by IP or Basic authentication) because it will not have all the latest security fixes. You can give a subdomain such as 12x.example.org And when it hasn't been used in a long time, delete it. {REMARKSBOX} !!!# Automated cloning Same steps as above. Then, ((TRIM|#Automating_make_clone_and_upgrade|put on a cron job)) {REMARKSBOX(type="confirm" title="Use cases")} * A fail-over instance that has data which is maximum one day old ** If main site crashes and won't come back, then switch the DNS and the fail-over becomes the new production site. Then use other ways to restore the up-to-24 hours of lost data. Ex. from email alerts. * A local copy in the office: Staff can continue to work if server or Internet connection is down. (keeping in mind that any changes will need to be redone on real site later * A demo site: cloned each week from a template (reference) Tiki to show off some features. ** If this is a site with well-known passwords, you should add extra protection to this template site (like Apache Basic authentication) so only trusted editors modify it. {REMARKSBOX} !!# Test update or upgrade !!!# Manual * -+make blank+- instance to create an instance for the test upgrade * -+make clone+- and select from and to * select the version to update or upgrade to {REMARKSBOX(type="confirm" title="Use cases")} * Quality Assurance (QA): Test an update or upgrade in the context of realistic data and configurations so issues can be reported early and handled before the official release of Tiki. ** Detect regression bugs ** Detect undesired changes ** Detect performance issues ** Run a manual test plan or an automated test suite ** Test new features and thus, become familiar with them, and suggest improvements ** Check if a bug has been fixed *** If it's important, this indicates to the developers that a backport may be possible *** If it can wait until the next upgrade, their is nothing more to do. {REMARKSBOX} !!!# Automated Same steps as above. Then, ((TRIM|#Automating_make_clone_and_upgrade|put on a cron job)) {REMARKSBOX(type="confirm" title="Use case")} * ((tw:pre-dogfood)) servers. Ex.: next.example.org ** As above, but users are autonomous to check this any time and always have latest data (copied from production) and latest code. {REMARKSBOX} !# Future use cases !!# Re-install and apply a profile !!!# Manual * -+make instance+- and -+make profile+- * adjust your profile * re-install Tiki and re-apply the profile * adjust your profile until the final result is just right !!!# Automated Same as above, on a daily or weekly cron job ^ Use cases: * Demo sites * Development process for complex projects with several developers ** Thus, everyone on the team has the same data to test/develop with. ** This is how CartoGraf was developed. Thus, the profile was applied hundreds of times before being applied in production * Automated testing: Tests can automated to detect regressions. ^ !!# Dev-testing-acceptance-prod workflow * Some features are missing in Tiki and TRIM to do this well ** Relations between Tiki instances (This is the dev of this other one) ** To be able to migrate data, without touching the code. Ex.: copy latest production data to the dev server (but not touching the code) !!# Show server * https://dev.tiki.org/show.tiki.org-Overview !!# Delayed mirroring Same daily operation as "Automated cloning" but with a lag (ex: one day, one week and one month). Suggested domain names include yesterday.example.org, aweekago.example.org and amonthago.example.org ^ Use cases: * A user reports an issue, and indicates that current behavior is different than previous behavior. Has their been a regression in the code? A change of configuration? Is the user mistaken? * Someone accidentally deletes a file or a tracker item, or some other operation for which their is no history (the logs indicate the action, but data is gone, so un-revertable): With aweekago.example.org, the user can find the info, and restore him/herself. ^ Tip: This site should restricted (ex.: by IP or Basic authentication) because it will not have all the latest security fixes. !!# Compare Tiki instances make compare should show a diff of all files in and outside the web directory, and a diff of database
Related content
