Есть три буддийских способа смотреть телевизор. В сущности, это один и тот же способ, но на разных стадиях тренировки он выглядит по-разному. Сначала ты смотришь телевизор с выключенным звуком. Примерно полчаса в день, свои любимые передачи. Когда возникает мысль, что по телевизору говорят что-то важное и интересное, ты осознаешь ее в момент появления и тем самым нейтрализуешь. Сперва ты будешь срываться и включать звук, но постепенно привыкнешь. Главное, чтобы не возникало чувства вины, когда не можешь удержаться. Сначала так со всеми бывает, даже с ламами. Потом ты начинаешь смотреть телевизор с включенным звуком, но отключенным изображением. И наконец, начинаешь смотреть выключенный телевизор. Это, собственно, главная техника, а первые две — подготовительные. Смотришь все программы новостей, но телевизор не включаешь. Очень важно, чтобы при этом была прямая спина, а руки лучше всего складывать на животе — правая ладонь снизу, левая сверху. Это для мужчин, а для женщин наоборот. И ни на секунду не отвлекаться. Если так смотреть телевизор десять лет подряд хотя бы по часу в день, можно понять природу телевидения. Да и всего остального тоже.

Виктор Пелевин, Generation П.

Організації такої схеми розробки сильно допомагає git або будь-яка інша децентралізована система контролю версій. Хоча технічні деталі стосуватимуться git, їх, мабуть, можна використати з іншою системою такою як mercurial чи bazaar. Тут можна похоліварити, я б почитав аргументовані коментарі щодо кожної з систем. Окрім власне самої системи контролю версій нам потрібно буде якийсь інтерфейс для відправки коду для перегляду, власне самого перегляду і обговорення. Користуючись git ви маєте надзвичайно крутий інструмент на платній основі — github. Якщо ж hosted-версія такого програмного забезпечення не підходить для бізнесу (з різних міркувань: безпеки, оплати, інші), тоді вам в пригоді стануть інші подібні системи: gitorious, gitlab (огляд на хабрахабрі), luna-tool (стаття на хабрахабрі). Варто відзначити, що останні дві системи доволі нові, відтак можуть не мати достатнього функціональності для тієї схеми, що я тут розповідаю і я їх не пробував особисто, проте вони швидко розвиваються і мають корені з недалекого східного зарубіжжя. В цьому записі я зупинюсь на gitorious, так як схема роботи побудована з використанням цієї системи.

Встановлення gitorious

Власне починається усе з встановлення. Інструкції до встановлення можна подивитись у вікі проекту. Рекомендую не встановлювати руками, бо з цим безліч мороки (я це робив двічі, обидва рази це мені зайняло приблизно 2 дні, я не рубі програміст). Якщо ви розробляєте на рубі щодня, то для вас це буде мабуть доволі легко. Для інсталяції є рецепти для chef.

Команди

Тут і надалі я буду використовувати gitorious.org для прикладів і скріншотів.

Після встановлення і авторизації, ви побачите приблизно наступну картинку.

Приборна панель Gitorious

Після цього приступимо до створення команд. Для цього у верхньому меню вибираємо Teams, потім Create Team справа.

Форма створення команди

Після цього додамо розробників в команду (думаю після встановлення ви створили аккаунти для розробників). Останні кроки варто повторити стільки разів, скільки команд у вас є.

Репозиторії

Далі створюємо проект і репозиторій з кодом проекту. Цей процес я описувати не буду, щоб не нагромаджувати статтю інформацією, яка не відноситься до основної ідеї. Припустимо, що на цьому етапі репозиторій вже є і почнемо створювати командні клони. На сторінці репозиторію нажимаємо кнопку Clone та бачимо наступну форму:

Форма створення клону репозиторія

Зауважте, що потрібно робити саме клон для Group, а не персональний. В дропдауні будуть групи, до яких ви належите. Задаємо назву репозиторію і готово. Як результат у команди буде своя копія репозиторію. В новостворений репозиторій лід команди буде відправляти коміти напряму, а інші члени команди повинні зробити персональні клони. Це робиться в спосіб, вказаний вище, тільки потрібно вибрати Me на формі створення клону.

Після цього команди і девелопери матимуть свої репозиторії. Також, створені репозиторії можна поділити на рівні, як зображено на рисунку нижче.

Рівні репозиторіїв.

Процеси розробника

Після налаштування команд і репозиторіїв пропоную ознайомитись з наступними процесами. Власне тут починається сам жир статті, до цього моменту була тільки підготовка до роботи. В описі процесів я рухатимусь знизу вверх з позиції розробника.

Перш за все розробник робить локальний клон свого публічного репозиторію. Це відбувається за допомогою наступної команди:

git clone git@gitorious.org:~xobb/gitorious/xobbs-feature-team-mainline.git

Також необхідно буде добавити репозиторій своєї команди

git remote add upstream git@gitorious.org:+feature-team/gitorious/feature-team-mainline.git

та головний репозиторій для оновлень

git remote add blessed git://gitorious.org/gitorious/mainline.git

Відповідно у розробника буде три наступних ремоута, які він використовуватиме щодня.

• origin — власний репозиторій для відправлення власних змін.
• upstream — командний репозиторій для інтеграції власних змін з кодом інших
• blessed — головний репозиторій для оновлень власного репозиторію.

Припустимо, що розробник отримує завдання. Його кроки виглядають наступним чином:

1. оновлення з головного репозиторію
2. створення локальної гілки з кодом, що вирішує завдання
3. відправлення локальної гілки в публічний репозиторій
4. повідомлення свого тім ліда про те, що завдання виконано і його необхідно переглянути, та відправити в головний репозиторій.

Пройдемо ці кроки на технічному рівні. Оновлення з головного репозиторію відбувається наступною інструкцією:

git pull blessed

Тепер створимо гілку для виконання задачі:

git checkout -b new-feature

Тут розробник вносить зміни в код. Що ще розказувати, за цим одним реченням написано мільйон книжок і статей, як це вірно робити. Коли все готово, тоді розробник відправляє зміни в свій публічний репозиторій:

git push origin new-feature

Як ви мабуть помітили, попередні кроки були зроблені без використання gitorious, ця функціональність є в будь-якої розподіленої системи контролю версій. Колись, на ранніх етапах розвитку git, розробник відправляв листа своєму ліду з проханням переглянути і змерджити код, даючи необхідні для цього дані: url власного публічного репозиторію, назву гілки. Це звісно дуже сумний і драматичний результат роботи. Щоб такого не було, нам на допомогу приходить gitorious.
Відправивши гілку з готовим кодом в публічний репозиторій, розробник створює мердж запит для повідомлення тім ліда. Це виглядає наступним чином:

Форма створення мердж запиту

Вибачайте за якість цього скріншоту, я їх з двох ліпив і аж спеціально Gimp поставив. Зверніть увагу на секцію Select commits, там можна вибрати ті коміти, що ви хочете включити в мердж запит. Коли ви натиснете кнопку Create merge request то лід отримає повідомлення і також зручний інтерфейс для перегляду змін, з можливістю пострічкового коментування коду, версійністю. Дивіться скріншот нижче.

Інтерфейс перегляду мердж запиту

На цьому етапі робота розробника закінчується і ми переключаємось на тім ліда, який власне займеться кодом далі. Розробник в свою чергу може приступати до виконання наступного завдання.

Процеси тім ліда

Так як тім лід теж зазвичай залучений в процесі розробки, то він теж працює з репозиторієм, але в силу того, що нікому переглядати його код, то він працює з командним репозиторієм напряму. Відповідно тім лід клонує командний репозиторій:

git clone git@gitorious.org:+feature-team/gitorious/feature-team-mainline.git

І додає головний репозиторій для отримання оновлень та відправлення своїх змін та від інших членів команди.

git remote add upstream git@gitorious.org:gitorious/mainline.git

Припустимо, що тім лід задоволений якістю коду, що розробник йому запропонував мердж запитом і він хоче його прийняти. Для цього потрібно виконати наступну інструкцію:

git pull origin refs/merge-requests/1

1 в даному випадку зазначає номер мердж запиту. Відповідно код, отриманий при мердж запиті потрібно відправити в головний репозиторій. Зробимо це:

git push upstream

Висновки

Власне на цьому можна закінчувати статтю, проте ще якось варто б підсумувати. Ця схема роботи працює. Її введенню передував перехід проекту з svn на git. З часу впровадження суттєво знизився колективний стрес в командах, код став стабільніше і проект більш керованим. Розробники почали більше експериментувати, перестали боятись вносити значні зміни в код, робити рефакторинг коду. Більше того, в процесі почались довгострокові зміни в незалежних гілках з великими новими напрацюваннями, що значно полегшать розробку, проте не являються основними в системі.

Також зверніть увагу, що при операціях pull і push я не вказував гілки. Зазвичай це потрібно робити! Інакше ви можете отримати не той результат, який очікуєте.

Такий підхід я б не назвав фінальним. Його можна удосконалювати в багатьох аспектах. Для прикладу введення посади реліз менеджера зможе вирішити момент з динамічним формуванням релізів. Тобто людина збиратиме з командних репозиторіїв мердж реквести з готовим функціоналом і формуватиме реліз на вимогу включаючи тільки певні функціональні модулі. Я б з радістю почитав про інші схеми роботи.

Аутсорсингові компанії зазвичай мають більше бюрократичних правил (які, чесно кажучи, оправдані), що необхідно слідувати під час розробки. Від релізу до релізу потрібно робити код рев’ю, планувати спрінти, розділяти відповідальність на групи розробників всередині команди. Такий процес провокує взаємодію між людьми. Як відомо, коли проблема стосується людей то її вирішення значно складніше і менш універсальне, чим рішення, що знаходиться в технічній сфері.

Отож як гіт може допомогти нам в код рев’ю, поділ відповідальності на групи розробників і оформлення релізів? Давайте розглянемо на прикладах. Уявимо що в нас є декілька feature-команд, що займаються розробкою нового функціоналу до уявного продукту і декілька maintenance-команд, що займаються підтримкою існуючої системи і мінорними покращеннями до продукту. На схемі 1 нижче зображено все що ми тут науявляли.

Схема 1

Звісно кожна команда створює свої гілки в основному репозиторії, там собі девелопає успішно, обмінюється комітами, але все-ж залишається гетерогенною групою програмістів. Тому перше, що варто зробити це надати кожній групі свого публічного репозиторію. Мабуть група має якогось лідера (team-lead, старший інженер). Ось його публічний репозиторій може виступати в якості групового публічного репозиторію. Відповідно ми отримуємо групи двох рівнів: старші інженери і девелопери.

Старші інтежени рулять командним репозиторієм і комітяться туди безпосередньо, а девелопери ролять клони і девелопають в своїх клонах, відправляючи мердж реквести.

Відповідно ми наближаємось до схеми диктаторів-лейтенантів, яка характерна для розробки ядра Лінукса, тільки без диктатора. Хоча позицію диктатора може займати скраміський реліз менеджер. ВІн власне буде відповідальний за оформлення релізу, вибиратиме стабільні бранчі і включатиме їх в реліз.

Якщо вас ця тема зацікавила ,залиште будь ласка відгука і я розгорну її детальніше. Маю досвід впроваждення такої схеми в проект з 15+ девелоперами в 4 командах. Такі діла.

З того софта, що я використовую, все відмінно працює і на маверіку.

P.S.: Аля, пробач мене будь ласка, я мав піти спати в 12ій, але трохи затримався.

Click here to view the embedded video.

Click here to view the embedded video.

git status –include-untracked

Або ж просто -u стешне ще й нові файли, які наразі не під версійним контролем. Так як я стешусь по декілька разів на день і переключаюсь на інші бранчі, то ця фіча мені дуже пригодиться. Думаю вам теж сподобається.

git submodule update

Трохи його поремонтували. Коли ставалась помилка, то апдейт тупо вмирав. Тепер же він не буде вмирати, а просто вкінці роботи скаже вам про помилки. Знову ж таки зручність во всє поля.

Кароче, якщо я вас не переконав апдейтнутись, то ваші справи. А я апдейчусь.

Дерева замість списків

Your mother is so fat, she sat on a binary tree and turned it into a linked list in O(1) time.

Ех, крутий я. Як хароший писатєль вже починаю з цитати невідомих людей.

Давайте намутимо приклад такий, навколо якого будемо це все обговорювати. Допустимо у нас є сутність подорож. Вона складається з точки відправлення, точки прибуття, зупинок, що будуть зроблені під час подорожі (тобто якихось локацій). Також що ж за подорож без людей. Вона сама по собі не може бути, тому ми маємо людей, які подорожують. Також для повноти експерименту вкажемо дату відправлення і дату прибуття для подорожі. І ми ці подорожі каталожимо: кожен приходить, каже що був в такій і такій подорожі з такою і такою людиною.

Для людини, яка має достатньо досвіду з реляційними базами даних одразу стане перед очима наступна схема реалізації згаданого вище:

Малював на швидкоруч в гуглодоці, так шо вибачайте за карявість, але надіюсь що суть донесена. Маємо три зв’язка один до багатьох і два зв’язки багато до багатьох. Тепер припустимо, ми хочемо знайти всі подорожі, що почались з Тернополя за вересень минулого року. Для цього робимо наступного запита:

Однак з документноорієнтованим сховищем все трішки не так. В нас немає аналогу джойна, тому ми повинні імпровізувати. Взагалі-то мабуть це не буде імпровізація, тут скоріше поломка мозгів сталась. Буквально як Лінус казав, якщо людина дуже довго користується SVN або CVS, то вона втрачає розуміння і бачення того, як би мала виглядати система контролю версій. Так от, працюючи з плоскими структурами ми забуваємо як би мала виглядати деревовидна.

Хех, містере Хобб, скажете ви. А ми тут з пустині сад зробимо і на вашу деревляну структуру навішаємо купку зв’язків. У нас є можливість до реквеста чіпляти айдішки користувачів, локацій, а зв’язки багато-до-багатьох ми ващє в масиви позапихуємо і буде в нас навіть без сурогатних сутностей, як це положено в реляційній моделі. І шо на це скажете?

Дійсно, після тривалої роботи з реляційними базами даних таке бажання не приховаєш. Англійською є гарненьке слово temptation. Проте, якщо ви звернете увагу, вищезгадана задача з вибіркою подорожей з Тернополя за вересень стане ох як нетривіальною. Сильно-сильно нетривіальною.

І що ж робити?

Та воду слівать. Треба сісти і не піддаватись бажанню робити зв’язки, а робити вкладення. Дерева для того і дерева, щоб мати гілки. Тому визначаємо основні сутності нашого каталогу подорожей і ставимо їх во главу столу. Очевидним шо в каталозі подорожей, подорожі будуть основною сутністю. Також важливою сутністю будуть користувачі. Але ось локації без контексту подорожей не мають ніякого сенсу. Тому об’єкт подорожі у нас виглядатиме наступним чином:

Зверніть увагу, так як ми сутність користувача не вносимо в дерево, тому ми використовуємо зв’язок по унікальному ідентифікатору (MongoId). Тут абсолютно up to developer що використовувати. Хлопці з 10gen говорять:

If performance is an issue, embed.

Я не став перевантажувати об’єкт MongoDate. Цей тип рекомендується викоритосувати для збереження будь-якої часової інформації. Ну ви поняли.

З такою схемою запит на отримання усіх подорожей по критерію буде доволі таки простий:

Денормалізація

Замість висновків. Прихильники реляційного підходу одразу помічають денормалізацію, перевантаженість однієї сутності іншою і т.д. Насправді документоорієнтовані бази даних не мають ступенів нормалізації і тут потрібно керуватись прагматичним началом в підході. Спочатку незручно, але згодом розумієш, що заради швидкодії і зручності можна пожертвувати якимись абстрактними нормами формалізації.