Revision as of 15:31, 25 August 2011 (view source) StasFomin (Talk | contribs) ← Older edit		Revision as of 15:32, 25 August 2011 (view source) StasFomin (Talk | contribs) Newer edit →
Line 1:		Line 1:
−	<slideshow title="" style="devconf" scaled="true" font="Calibri, Segoe Print, cursive" footer="" headingmark="⌘⌘" />	+	<slideshow title="" style="whalerider" scaled="true" font="Calibri, Segoe Print, cursive" footer="" headingmark="⌘⌘" />
	<slides float="right" width="300">		<slides float="right" width="300">
	Ride the Walrus — подход к выбору и интеграции		Ride the Walrus — подход к выбору и интеграции

---

Revision as of 15:32, 25 August 2011

Мы хотим кратко рассказать историю развития open-source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки.

У нас она начиналась с идей:

Open-Source

нет жестких ограничений — гибкость и опыт масс в одном флаконе.

Wiki + баг-трекер + система контроля версий

достаточно для всего.

Правильная вики ⇒ MediaWiki

мэйнстрим + расширяемость.

Кроме того, мы (в конце 2010г) наконец-то выполнили обещание выйти в Open-Source и теперь существует проект 4intra.net («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками.

Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как

• система информационных потоков (читай — форумов и блогов),
• презентаций,
• опросов и экзаменов,
• личный «кэш» сетевых закладок

и так далее.

Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».

О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад.

Wiki-Way и выбор систем

При начале разработки дизайн чего-то нового, доселе неизведанного, обычно либо глубоко проектируется в самом начале (инженерный подход), либо эволюционирует, начиная с заложенного изначально минимума.

Wiki-Way мы называем именно натуральный эволюционный подход с максимально упрощёнными концепциями. Вообще говоря, кто-то другой мог назвать его ещё как-нибудь — хоть «Web 2.0», хоть «гибкий», хоть «Agile», но мы выбрали термин «Wiki-Way» — Wiki являются его апогеем.

Этот конфликт, между «жестким, заданным априори» и «гибким, адаптирующимся к меняющимся потребностям пользователя и ограничениям среды» встречается повсеместно. В культуре разработке кстати тоже, рекомендуем вам взглянуть на книгу «lib:Культуры программных проектов (Энтони Лаудер)» — там этот конфликт выражен противоречием между «заводской» и «сервисной» культурой (offtopic: с очень неоднозначным положением культуры «дизайнерской»).

Выбор систем

«Ящик Вендора»

Закрытые платные системы крупных производителей («вендоров»).

«Велосипед» или «Лунапарк»

Да, то самое, что нестерпимо хочется изобрести самому, и сделать это обязательно с блекджеком и шлюхами ©.

«Жадный интегратор» или «Футбол Хоттабыча»

поставить все что можно (особенно если бесплатные системы) и потом пытаться все это интегрировать, а пользователей учить всем этим пользоваться.

Ящик Вендора: Плюсы? Минусы? ⌘⌘

• Сильносвязанный
  • «☺ Отлично, всё интегрировано?»
  • ☹ Шаг в сторону — считается побег !
    
  • ☹ Меньше думать может оказаться вредно
• Закрытый
  • «☺ Кому в нём копаться?»
  • ☹ Недостатки не исправить !

Велосипед

YATUP ⌘⌘

CLOC ⌘⌘

• MediaWiki: 185000 PHP, 577000 локализация
• Bugzilla 3.6: 72000 Perl, 35000 TT
  • 4.0: +10000 Perl, +3000 TT

И в них ведь есть какой-то смысл (!)

Может, не стоит писать заново ?

Сочетание систем

Идея родилась у нас ещё N (≈ 8) лет назад^[1], а в последнее время, похоже, распространяется всё больше и больше, возьмите хотя бы Google Code или любой GitHub / Bitbucket / Launchpad.

Логика была следующая — почти все объекты, с которыми приходится иметь дело разработчику, можно разделить на три части:

Ответственность

то, что нужно сделать или исправить, в каком состоянии какие задачи, проблемы и ошибки, кто за них ответственный и т.п.

Артефакты

всё то, что является результатом разработки. Код, дистрибутивы, отгружаемая документация.

Знания

то, благодаря чему разработка становится возможна. Аналитика, крупные постановки задач, функциональные и нефункциональные требования, документация (внутренняя и внешняя и т.п.).

В этой троице каждому из типов соответствует (одна!) своя система, что и даёт такое удобство. Wiki для знаний, VCS для артефактов, issue-трекер для задач и багов.

Частично они могут пересекаться. На самом деле, набор этих систем столь мощный, что можно «отрубить» одну или даже две, и оставшиеся всё равно будут пытаться «покрывать» большую часть процессов. И при этом они будут конкурировать, и вытеснять более специализированные системы^[2]. Ну и мы знаем несколько неудачных случаев попытки интеграции большего числа более специализированных систем (подобранных по принципу «футбол Хоттабыча» — «для каждого типа объекта в разработке пусть будет самая лучшая специализированная система его учета»)^[3]

С чем имеет дело разработчик? ⌘⌘

• Код, тесты
• Баги, задачи, постановки
• Документация
• Новости, обсуждения
• …

А бешеный заяц на слайде выше — это Мартовский заяц из Диснеевской Алисы в Стране чудес, иллюстрирующий CVSnt, очень сомнительного качества доработанный CVS, произведённый на свет компанией March Hare Software.

Кстати, в это трудно поверить, но надо признаться, что у нас в компании до сих пор есть проекты использующие CVS. Использование CVS обусловлено накопленным legacy-опытом (специальные утилиты deploy и testing, завязанные на CVS), плюс legacy-технологии таковы, что переход на SVN или DVCS почти ничего не дает (ветвится вокруг неизменной терабайтной базы бессмысленно, переименования серверных пакетов чрезвычайно редки и т.п.). В общем, CVS у нас работает, как до сих пор работают паровозы в Китае, и мы рассчитываем, что он отомрет естественно, вместе со сменой legacy-технологий.

ViewVC

ViewVC^[1].

Для нас большой плюс, что он поддерживает и SVN и CVS (см. выше).

ViewVC ⌘⌘

ViewVC → web-интерфейс к CVS & SVN

• Его можно считать частью VCS.
  • У git и hg веб-интерфейс вообще в стоке.
• Тоже чуть докручен

Трекер и вики

Epic Win’ы MediaWiki ⌘⌘

• Расширяемость:
  1700 расширений и очень легко пишутся
• Отсутствие суррогатных ID:
  http://lib.custis.ru/Как_прекратить_писать_(Андрей_Аксенов_на_ADD-2010)
• Производительность и кэши:
  Ну, Wikipedia же ворочается!
• Локализация:
  352 локали (!)

Альтернативы

Далее мы рассмотрим некоторые альтернативы своему выбору - может быть, не до конца оптимальному, но выросшему эволюционно и используемому успешно.

VCS

Что такое VCS (система контроля версий), надеемся, известно всё-таки уже всем^[1]. Для тех, кто в танке — это система, помогающая хранить не одну версию файлов продукта, а много сразу, в любой момент возвращаться к любой версии, просматривать информацию о версиях и т. п. Первой системой контроля версий был RCS, потом из него вырос CVS, а после CVS появился Subversion для «свержения» (англ. subversion) и исправления недостатков CVS’а.

CVS и Subversion — наиболее распространённые представители централизованных систем, в который репозиторий (хранилище версий) располагается на одном «центральном» сервере, а на компьютерах разработчиков размещаются только «рабочие копии», соответствующие какой-то одной версии. Модной в последнее время альтернативой этому подходу являются распределённые системы управления версиями, хранящие весь репозиторий в каждой рабочей копии.

Что важно для удобства, DVCS поддерживают расширенные возможности отслеживания ветвлений и объединения изменений, потому что без этого объединять безумные графы изменений, приходящих от разных разработчиках в OpenSource проектах, было бы невозможно.

Самые известные lib:DVCS — это Git, Mercurial (hg) и Bazaar. Возможно, вы также слышали о Darcs и Monotone. Хранение полной истории ревизий в каждой рабочей копии, кроме всего прочего, даёт ещё и «естественное резервное копирование».

DVCS сейчас действительно «в моде», это даже подтверждают данные двух одинаковых опросов от 26 октября 2009 и 2010 годов на Хабре — SVN и CVS потеряли 3 % и 5 %, а Git и Hg приобрели те же 5.5 % и 3 %.

Bazaar, правда, потерял полпроцента (а я говорил! И не только я).

Так или иначе, производимые артефакты хранятся в системе контроля версий, этим уже никого не удивишь, запомним это.

Статистика ⌘⌘

DVCS в моде ⌘⌘

За год:

• Git, Hg ↑ 5.5 %, 3 %
• SVN, CVS ↓ 3 %, 5 %
• Bazaar ↓ 0.5 % (hate and hate)

Недостатки DVCS — текст

Есть у DVCS и некоторые недостатки: например, то, что размер репозитория со временем сильно растёт, не очень удобно. Хороший пример — это исходники Андроида, хранящиеся в Git. Чтобы попытаться собрать хотя бы recovery (образ «консоли восстановления» для телефона), нужно выкачать 4.8 Гб исходников! Также, говорят, бывает, что разработчики начинают много коммитить локально, а потом «сбрасывают кодовые бомбы» на остальных. Как к этому относиться — личное дело каждого, можно считать, что виноваты всё-таки разработчики, а не DVCS (те самые «80 %» разработчиков — наверное, быдлокодеров). Также менеджеры негодуэ, потому что невозможен контроль доступа к частям репозитория. Но если это жмёт, нужно просто разбить репозитории на несколько и немного упростить выдачу прав. Ну, а «корпоративный народ» может отнестись к этим системам, пришедшим из мира Opensource, не очень хорошо. В общем и целом, все недостатки решаемые.

Bug Tracker

Bug Tracker — это система отслеживания задач (а не только ошибок). Очень часто «баг» рассматривают именно как «ошибку», хотя это вопрос терминологии — в реальности, «багом» можно назвать любую задачу, запрос и т. п. — любое нечто, исходящее от кого-то одного и требующее реакции от кого-то другого. В силу широты формулировки и наличия большого множества задач, большинство баг-трекеров устроено и выглядит монстровато.

Казалось бы, и баг-трекером уже никого не удивишь, но оказывается, и это не так. Часто для разных задач используется всё что угодно, но только не баг-трекер. Причиной для этого может являться чрезмерная «специфичность» используемой системы, когда менеджерским взглядом в неё вкручены диаграммы Ганта и прочие радости (один из разработчиков Luxproject’а использует для разных задач всё что угодно, только не Luxproject^[1]).

Bug Tracker ⌘⌘

• «Bug» != «Ошибка» ! ! !
• «Bug» = ∀ (любая) задача:
  • Ошибка, запрос фичи, вопрос поддержке

Хотя различать любят:

…I define a bug as behavior in a «Done» story that violates valid expectations…

Wiki

Сейчас на дворе уже третье тысячелетие, через пару лет, то ли конец света будет, то ли Великая Сингулярность, то ли нефть кончится, и рассказывать что такое вики-системы и чем они хороши, вроде как страшный баян. И все же, если вдруг будет время, то у нас (опять-таки!), есть статья и выступление на конференции по этой теме^[1].

Вики-движки ⌘⌘

http://wikimatrix.org/ - вики-движков > 130!

Популярные:

MediaWiki Template:Localimage:MediaWiki-notext.svg" width="64" /> (Wikipedia)	MoinMoin Template:Localimage:Moinmoin.svg" width="64" />	DokuWiki Template:Localimage:Dokuwiki-128.png" width="64" />

Win / Fail ⌘⌘

Win: гипертекст^{в абсолюте} ! ☺

Fail: плохо с атрибутикой ☹

• Однако, гипертекст rules, если есть поиск*
• Есть Semantic MediaWiki

* Goo… Guess who?

4intra.net и наши доработки

Однако «дикая» MediaWiki для компании-разработчика не особо хороша, и конечно при сравнении «в лоб» проигрывает «специально обученным корпоративным вики-системам».

Но если «укротить» и немного обработать напильником, MediaWiki становится фантастически удобной системой для компании-разработчика, решающая практически все проблемы управления знаниями, требованиями, тестами и т. п., которые могут возникнуть^[1].

Затратив еще немного сил (как обычно, с использованием «напильника и такой-то матери»), можно эффективно «увязать» то небольшое число готовых, вышеупомянутых систем, получив шикарный интранет-разработчика «with Black Jack & Hookers»©^[2].

И мы уже прошли этот путь, отобрали самые интересные расширения, доработали и переработали их, написали кучу своих, и даже решали проблемы производительности и разгона^[3], управления правами (самое уязвимое место «природной MediaWiki»), научив все веб-системы не только «плеваться почтой», но и смиренно отдавать RSS-feedы, а всех сотрудников — пользоваться RSS-агрегаторами (и даже развернув корпоративный «Google Reader» — FeedOnFeeds. И все это готовое предлагаем вам совершенно свободно и даром^[4].

Нет, это не было изобретением велосипедов, объем доработок по сравнению с объемом trunkа был невелик, сначала это было практически хобби (10 % времени) одного веб-любителя, но теперь этим (хотя и не на 100 %) стал заниматься настоящий веб-профессионал, и нам уже не стыдно выкладывать все это в open-source.

Кроме того, большинство доработок оформлены в виде расширений MediaWiki, и поэтому в будущем не умрут, как это обычно случается с «велосипедами», а останутся рабочими и доступными для сообщества.

FeedOnFeeds ⌘⌘

4intra.net ⌘⌘

Opensource с декабря 2010

• MediaWiki4Intranet
  • ~60 расширений, ~40 патчей, установка hg clone
• Bugzilla4Intranet
  • > 100 фич/изменений

Mindmap ⌘⌘

Медиавозможности ⌘⌘

• LaTeX
• Graphviz, UML, Gnuplot
• SVG, PDF, DjVu, TIFF, Flash Video, Mindmap
• подсветка синтаксиса

Wiki-плюшки ⌘⌘

Презентации Блоги/форумы* Календарь Опросы, экзамены

ВикиЗакладки Развесистые права Импорт/экспорт ...

* что почти одно и то же

Интеграция ⌘⌘

Ещё интеграция ⌘⌘

Куда двигаться дальше? ⌘⌘

• Правильная Bugzilla
  • ??? а стоит ли?
• Тесты, code review → Wiki
• Semantic Wiki

Правильная Bugzilla ⌘⌘

• С одной стороны, Bugzilla отстаёт от bleeding-edge
  • Usability + Refactoring
• Зато пока остальные делают , она сохраняет HTML-простоту
• А потом нагонит на стандартах

LOR, Debian vs Ubuntu ⌘⌘

> этих хомячков в сотни раз больше и именно на них ориентируюся производители ОС

Когда делают операционную систему по dfsg, тогда ориентируются, прежде всего, на dfsg, а не играют в волшебников с голубыми вертолётами «хрен с ней, со свободой, главное игрушки». И благодаря этим неволшебникам, и существует, в том числе и убунта.

Ну будет Debian делать всё, как убунта, получится две убунты и ни одного дебиана, и, как следствие, ни одной убунты.

Не учите отцов, как им делать. Особенно, если вообще ничего не понимаете и ничего не решаете, а просто плывёте в потоке, ведь это единственные, кто думают о вашем завтра, чтобы не оказалось, что завтра вы уже не контролируете ровным счётом ничего.

Usability ⌘⌘

• JS grid
• «Форум-функционал»
• Agile
  • (вкрутить разумный минимум)

Refactoring ⌘⌘

• Переделать систему прав*
  • * кто-то понимает MANDATORY/SHOWN/DEFAULT/NA ?
• убить YAHOO UI → jQuery
• копипасту → прокачать объектный движок
• CGI.pm (детище 90-х…)
• Template Toolkit
  • или хотя бы обратную связь из шаблонов

Semantic Wiki ⌘⌘

• «Семантическая Wiki»,
• Она же Wiki с атрибутикой - http://semantic-mediawiki.org/
• Semantic Tracker
  • В пень Custom Fields!

Примечания

---

Статья отреплицирована из внутренней базы знаний компании.