|
Эволюция Wiki-Way командной разработки — различия между версиями
Материал из CustisWiki
|
|
Строка 6: |
Строка 6: |
| В докладе мы хотим кратко рассказать историю развития Open-Source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки. У нас она начиналась с идей — (1) '''Open-Source''', (2) '''Wiki + баг-трекер + система контроля версий''', (3) '''расширяемость => MediaWiki'''. Кроме того, мы наконец-то выполнили обещание выйти в Open-Source и теперь существует проект <span style="font-size: 150%">'''[http://wiki.4intra.net/ 4intra.net]'''</span> («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками. | | В докладе мы хотим кратко рассказать историю развития Open-Source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки. У нас она начиналась с идей — (1) '''Open-Source''', (2) '''Wiki + баг-трекер + система контроля версий''', (3) '''расширяемость => MediaWiki'''. Кроме того, мы наконец-то выполнили обещание выйти в Open-Source и теперь существует проект <span style="font-size: 150%">'''[http://wiki.4intra.net/ 4intra.net]'''</span> («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками. |
| | | |
− | Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как систему '''форумов и блогов''', '''презентаций''', '''опросов и экзаменов''', личный «кэш» '''сетевых закладок''' и так далее. Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах». | + | Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как систему информационных потоков (читай — '''форумов и блогов'''), '''презентаций''', '''опросов и экзаменов''', личный «кэш» '''сетевых закладок''' и так далее. Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах». |
| | | |
| О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад. | | О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад. |
Версия 11:34, 28 апреля 2011
Аннотация
В докладе мы хотим кратко рассказать историю развития Open-Source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки. У нас она начиналась с идей — (1) Open-Source, (2) Wiki + баг-трекер + система контроля версий, (3) расширяемость => MediaWiki. Кроме того, мы наконец-то выполнили обещание выйти в Open-Source и теперь существует проект 4intra.net («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками.
Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как систему информационных потоков (читай — форумов и блогов), презентаций, опросов и экзаменов, личный «кэш» сетевых закладок и так далее. Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».
О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад.
Итак, теперь об идеях — Идея № 1: Open-Source. Начиналось всё с того, что из доступных вариантов —
- «Ящик Вендора»
- ☹Платный, сильно связанный, закрытый, производимый заданным вендором инструментарий.
Почти всё это кто-то может сформулировать и как плюсы: «платный => наверное, качественный?!», «сильно связанный => удобно, всё интегрированное?!», «закрытый => кому нужно в нём копаться?!», «производимый вендором => хорошая поддержка?!». Однако мы считаем, что всё это — минусы. Стоимость лицензий может превышать стоимость неплохого оборудования. Связанность убивает гибкость — шаг в сторону от вендорских инструментов, и работать уже неудобно. Закрытость не даёт исправить недостатки или неудобства, которые наверняка вскроются. Раз производит всё это вендор, вы должны слепо доверять его выбору инструментов.
- «Велосипед»
- ☹Полностью внутренние инструменты, созданные своими руками.
Сейчас, во времена LAMP, node.js и прочих языков и фреймворков быстрой веб-разработки, написать новую веб-систему не составляет никакого труда. Однако это грозит вам никому не нужным «велосипедом», жёстко завязанным на внутренние процессы компании, который со временем может стать (и наверняка станет) очень тяжело поддерживать.
- OpenSource
- ☺Поддерживаемые большими внешними сообществами, свободные mainstream-инструменты, «прирученные» и «допиленные» для внутреннего использования.
Единственная проблема здесь — свободных систем стало много и нужно сделать правильный выбор. Но — после этого вы совершенно бесплатно получаете мощнейшие инструменты, можете сами решать, сколько вы хотите приложить усилий к «допиливанию», точно знаете, что выбранные инструменты «не умрут» завтра, и имеете полную свободу всех действий, да ещё и можете сами сделать что-то хорошее!.
— из доступных вариантов мы выбрали OpenSource, и теперь — Good News, Everyone! — можем рассказать о наборе свободных систем, которые успешно используем в компании. Более того, это не просто слова — «Talk is cheap. Show me the code.» (c) Linus Torvalds — мы наконец-то выполнили своё обещание о выходе в Open-Source и теперь вы можете сами попробовать эти инструменты, причём, со всеми нашими доработками.
Идея № 2 — «Вики-Трекер-VCS», которая родилась у нас ещё N (≈ 7) лет назад, а в последнее время, похоже, распространяется всё больше и больше, возьмите хотя бы Google Code или GitHub. Идея заключается в том, что почти все объекты, с которыми приходится иметь дело разработчику, можно разделить на три части:
- Требования — то, что нужно сделать, то есть, все виды постановок задач
- Артефакты — всё то, что является результатом разработки
- Знания — то, благодаря чему разработка становится возможна
В этой троице каждому из типов соответствует своя система, что и даёт такое удобство. Wiki для знаний, VCS для артефактов, баг-трекер для требований. Частично они могут пересекаться. На самом деле, набор этих систем столь мощный, что можно «отрубить» одну или даже две, и оставшиеся всё равно будут пытаться покрывать большую часть процессов.
Хороший пример — расширения MediaWiki (скажем, WikEd), у которых Wiki зачастую служит и системой контроля версий (код кладётся прямо на страницу), и баг-трекером (в обсуждении).
Итак, допустим, мы определились с идеями — осталось лишь подобрать правильные системы и связать их воедино.
- VCS: Subversion — на данный момент вершина эволюции централизованных VCS. Также у нас до сих пор живёт CVS. + ViewVC — веб-интерфейс и поиск к ним.
- Wiki: MediaWiki — самая мощная, расширяемая и, наверное, самая широко используемая Wiki-система. Есть более 1700 расширений к ней. Другие популярные Wiki сейчас — это в первую очередь MoinMoin и DokuWiki. Важное отличие MediaWiki от многих других систем — достаточно выверенная концептуальная архитектура.
- Трекер: Bugzilla — широко распространена, хорошо поддерживаема и весьма мощна. Из минусов — немного заточена под баг-трекер Mozilla, legacy-продукт, инертные разработчики, не очень с юзабилити. Вообще, правильно выбрать трекер сложнее всего — либо это монстры (Bugzilla, Jira), либо слабы для интранета (Trac, Mantis, Roundup)… Поэтому здесь мы выбрали mainstream — то, что используется давно и довольно успешно.
Третья идея — использовать мощную концепцию MediaWiki — страницы, отсутствие суррогатных ID, служебные страницы для специального функционала, мини-язык парсера со включениями шаблонов, функциями парсера, вставкой изображений и других медиаданных и так далее, и хорошую поддержку для расширения всего этого.
Куда двигаться дальше
В сторону эволюционных (не революционных!) методов создания «правильной багзиллы», свободной ото всех недостатков оригинальной:
- Юзабилити: показывать историю изменений в комментариях, добавить ленты обновлений, форум-функциональность, Grid, теги
- Трепанация внутренностей: Переделать JS-часть (убрать YAHOO UI), переделать систему прав, прокачать объектный движок, выкинуть CGI.pm, шаблонизатор
В связи с теперешней популярностью SCRUM’а и Agile-разработки в целом — в сторону добавления механизмов интеграции с Agile — например, построения графиков Burndown, карточек.
В сторону выявления практик использования Wiki как системы тестирования и упрощения этого.
В сторону Semantic MediaWiki, а точнее, «вики с атрибутами страниц» — то есть, ликвидировать слабость MediaWiki в хранении сильно структурированных данных (а не плоского текста).
В сторону привлечения сообщества к проекту :)
|
![](/skins/custisru/headline_right.gif) |