(I've never tried this, and would still want my handy db dumps around, but I'm old fashioned. If your wiki server is running on a VM, you could just take a snapshot of the VM with a pre-determined frequency, save it someplace useful and spin it up somewhere else and then change the IP. You can even easily run full-scale DR testing from it with a simple IP change. Just stop your syncs and spin up the alternate site. Assuming that you have several sites, having regular testing is somewhat trivial. That's the kind of backups that can sit on your alternate hot-site. It's a database, a directory and a webserver. (Confluence also has a "Everything to PDF" function which is kind of neat in a pinch)īacking up and restoring a complete mediawiki is fairly trivial. It's not completely usable off-the-cuff if you have lots and lots of little articles, but it's a good start. Then just sync the files to someplace else. I disagree with your complaints about wiki during a DR, and have successfully used wikis during large disasters with the following methods:Ĭoding a script to crawl a mediawiki and dump every article to PDF is fairly trivial. You could also have a look at Gollum, I believe that's still the wiki behind GitHub's wiki pages.Īlso, for the love of all that is Holy, don't do Sharepoint. Confluence? I've also used Alfresco, which's API is very very well thought out, but the GUI is self immolation worthy. Or, if you'd rather not reinvent the wheel, then I guess. What wins do you have at this point : when your datacenter(s) go aflame, you have plaintext somewhere you can grep with your mom's Pentium and a Red Hat 3 CD-ROM, you can very easily backup your consumables to many locations, if you hate Atlassian's search as much as I do you can also index with whatever you like (Elasticsearch FTW). Automate the production of normie compatible output through CI and store the result wherever you like. (I've done LaTeX / PDF, ePub, static site, and plaintext archives in the past)īehold any CI tool of your liking : Jenkins, Circle, Travis, Concourse, whatever. Then, you decide on how you want normies / clients / other people to consume that documentation : web page, pdf, epub? Ok, cool. (I'm looking at you Atlassian! You standards rapist!)Īt this point, you have two wins already : you have full history of changes to your documentation, and you can debate a change to documentation as a pull request before committing it to master. You make a repo per documentation project. It is an extremely powerful, scalable software and a feature-rich wiki implementation that uses PHP to process and display data stored in a database, such as MySQL SlimWiki: An easy to use knowledge sharing platform for teams. That said, I've been successfully experimenting with an alternative : plain text + SCM.Īt my last and current workplace, I've implemented flows which go a bit like this : MediaWiki vs SlimWiki: What are the differences MediaWiki: A free and open-source wiki engine.It is a free server-based software. Most wikis provide painful processes at best to review changes to a document before they are committed. Most wikis are a pain to search (I'm looking at you Confluence) Most wikis are a pain to read when you're in the midst of a DR scenario (spotty internet, servers down, poopoo hitting the fan in unexpected ways) I've had a growing hate for wikis over the past years for the following reasons (and it leads to a suggestion, bear with me) :
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |