Как релизится GitHub

    Yac 2013 посетил Jason Rudolph из GitHub. Я считаю его доклад про API был одним из самых интересных на конференции. Яндекс обещал выложить в сеть записи, так что советую на досуге посмотреть его всем, кто не видел.

    Но речь пойдет не о докладе. На картинке график релизов GitHub на продакшн.



    Когда я услышал цифру, я не поверил своим ушам. У GitHub'а сотни обновлений в неделю. В команде около сорока разработчиков и ни одного QA.

    К счастью Джейсон после доклада еще какое-то время находился рядом со сценой и я смог расспросить его с пристрастием о том как они это делают.

    В GitHub'е живет Hubot. Сначала это был just4fun чат-бот. Со временем он научился открывать двери в офисе и… запускать выкладку на продакшн. В GitHub выкладку может запустить любой разработчик из любого фича-бренча простым сообщением в чат. Я часто и много занимаюсь релиз-менеджментом. Когда я услышал о таком порядке деплоя волосы на руках непроизвольно зашевелились. На самом деле, выложить «битый» релиз вам все-равно не дадут. Выкладка происходит следующем образом:

    • Если бренч не был смержен с мастером — смержить его
    • Запустить тесты
    • Запустить миграции
    • Выложить изменения в staff-only режиме
    • Если все хорошо, включить «публичный режим»
    • Проверить логи и твиттер на наличие ошибок/WTF-твитов
    • Если все ок смержить фичу в мастер

    Миграции БД

    База данных GitHub достаточно велика и миграции могут занимать длительное время. Поэтому они выполняются отдельно, перед тем, как выложить обновление. За все время работы Джейсон не припомнит, чтобы пришлось откатываться. Не смотря на это разработчики всегда пишут обратные миграции.

    Тесты

    Когда Джейсон пришел в GitHub, тестов было много и они выполнялись около двух минут. Сейчас их «очень много», но они выполняются за 50 секунд. В GitHub смогли добиться этого за счет параллелизации. Все тесты выполняются на 64 ядрах. После каждого выполнения среда анализирует какие пачки тестов выполнялись дольше других и в автоматическом режиме перераспределяет тесты так, чтобы все выполнялись примерно за одинаковое время. GitHub не использует Selenium, но у них есть юнит-тесты, интеграционные и системные end-to-end тесты. Вообще за автоматизацию всей этой кухни отвечает отдельный отдел DevOps, так что разработчики могут сосредоточиться на фичах.

    Staff-only

    Все новые фичи попадают сначала в, так называемый, staff-only режим. Сотрудники GitHub смогут их потрогать, для других фича будет «притворяться», что ее нет. Staff-only реализован в коде самого GitHub. Такой же идеей пользуются в IOS отделе Facebook. У них все фичи имеют тумблер «вкл/выкл». Это помогает выпустить релиз даже в случае если нужно экстренно «вернуть какое-то изменение обратно».

    Твиттер

    Джейсон шутит, что у GitHub самая лучшая команда тестировщиков — их клиенты. Если «что-то пошло не так» в твиттере сразу появляется аномальная активность. Этот Yac заставил меня по другому взглянуть на твиттер: кажется этот сервис все-таки можно использовать для чего-то более полезного, чем «мама, я покакала».

    Профессиональная этика

    Попасть на работу в GitHub — не самая простая задача. Каждый кандидат, даже если его порекомендовал кто-то из команды, изучается с пристрастием. Преимущество GitHub в том, что если у кандидата есть аккаунт, они получают достаточно много информации о претенденте. Внимание уделяется не только качеству кода, но и тому, поддерживает ли человек свой проект, как быстро отвечает на баг-репорты, сотрудничает ли с сообществом. Критериев много, но если коротко, то в GitHub работают люди, основная цель которых — выпустить классный продукт. Не самый классный код, дизайн, ui, алгоритм, а именно «продукт». Человеку должно быть важно «поставить» (to deliver) новую функциональность в срок и качественно. Это, пожалуй, то, что отличает больше всего «забугорных» разработчиков от наших соотечественников. Я глубоко убежден, что ориентация на продукт — это классно и нам нужно учиться этому у западных коллег.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 67

      0
      Картинка — эффект цикады?
        +21
        Ни одного QA, зато куча DevOps, которые пишут тесты.
        Магии нет.

          +14
          DevOps не пишут тесты. DevOps кодят инфраструктуру.
            0
            Для end-to-end тестов инфраструктура чуть ли не важнее самих тестов. Это для Unit-тестов соотношение Code LOC/Test Loc может быть меньше 1, а для end-to-end этот показатель обычно больше 100. Но вот написать его в виде автоматически выполняемого сценария очень сложно, ибо много инфраструктурных вещей надо сделать: базы поднять, настройки развернуть, запросы нужные сделать, данные базы посмотреть. Готового Фреймворка для этого нет.
              +2
              Как это нет? А Chef, Puppet, Ansible и еще десятки подобных инструментов?
                +3
                end-to-end действительно писать гораздо сложнее, чем юниты, но все-равно не корректно ставить равно между QA и DevOps. Вторые отвечают только за то, чтобы инфраструктура работала как часы. Если с этой инфраструктурой разработчики выкатят «сломанную» версию DevOps не расстроятся. Когда есть отдел QA разработчики склонны скатываться к отношению «чукча писатель, чкча не читатель». Мне очень понравилась профессиональная этика GitHub'а: пацан написал код, пацан проверил, что код работает.
              +1
              Может чат-бот умеет и тесты писать :-)
                0
                Здорово было бы, но ИИ пока не изобрели,… а если бы изобрели он бы и основной код писать смог )
                  +1
                  У яндекса есть роботестер :) Он сам придумывает и проводит тесты
                    0
                    Он не придумывает, там краулер скорее с набором правил. Вообще крутой проект. Кажется 12% или 19% багов находит он. Точную цифру Яндекс называл, но я не помню.
                      +4
                      Там интеллектуальный краулер. Который исходя из окружения поля ввода, перебора возможных состояний в графе, выбирает заданную глубину и ищет баги. Интеллектуальность заключается в том, что, например, в поле город, он введет именно город (помимо случайных величин для негативного кейса). Вот статейка про него habrahabr.ru/company/yandex/blog/193918/
                0
                DevOps — это не профессия/должность, я методология. Называть админов девопсами — то же самое, что называть разработчиков аджайлами.
                +21
                «научился открывать двери в офисе», а если обнаруживается проблема, двери запечатываются до исправления… SkyNet прям )
                  +5
                  Ага, и закрывать, пока сборка не позеленеет :)
                    +11
                    Ага, причем если время близится к обеду/концу рабочего дня, проверяет «зеленые» билды диффами. Если удаленных строк больше, чем добавленных, пишет «Are you kidding me?» и не открывает двери)
                      0
                      ugettext(«Are you kidding me?»)
                • UFO just landed and posted this here
                    0
                    Почему сроки должны удвоиться?
                    • UFO just landed and posted this here
                        0
                        То есть, если команда «такая», то от красивого кода отказываемся? Пишем говнокод!
                  • UFO just landed and posted this here
                    • UFO just landed and posted this here
                    +1
                    <think>Пошёл переносить свои проекты на github</think>
                    • UFO just landed and posted this here
                        0
                        Судя по частоте полосок — имеется тенденция к уменьшению частоты деплоев.
                        Чем это объяснить?

                        Стало меньше багов?
                        Стало меньше фич?
                        Деплои стали более объёмными?
                        Деплоить стало сложнее?
                          0
                          просто кто-то наверное ушел в отпуск
                            0
                            Какое-то время релизу дают «устаканиться», прежде чем накатывать новый. Это время фича-бренч не мерижтся в мастер, чтобы иметь возможность откатиться на последнюю стабильную версию. Возможно в конце месяца выложили что-то пожирнее, а в начале вносили косметические изменения. Количество деплоев же не самоцель. А вот то, что они имеют возможность так быстро обновлять продакшн — это круто.
                            +3
                            У них все фичи имеют тумблер «вкл/выкл»

                            Многие сейчас так делают, и один из примеров lanyrd
                            image
                            Кстати у них есть отличная статья о том как они развивались blog.natbat.net/post/61658401806/lanyrd-from-idea-to-exit-the-story-of-our-startup
                              0
                              Интересно сколько у них уже флагов этих накопилось? я так понимаю, знают единицы ( а может уже и никто не знает полностью) за что каждый флаг в точности отвечает и как влияет на другие флаги.
                                0
                                Судя по скриншоту — у них флаги под каждый отдельный feature-brunch. А флаги/branch`и можно и удалять по истечению определенного срока (к примеру когда фича уже стабильна ее просто добавляют в master).
                                0
                                А запись выступления выложили или пока ожидаем? Не смог найти у яндекса.
                                  0
                                  я не в курсе насчет выступления, но статью прочитал взахлеб :)
                                    0
                                    Пока еще не вложили, по крайней мере я тоже не нашел. По ссылке в статье есть слайды.
                                  +5
                                  Спасибо за статью!

                                  Но вывод… я бы не стал говорить о том, что в России разработчики не ориентированы на классный продукт. Классные/профессиональные разработчики всегда ориентированы в первую очередь на классный продукт.
                                    +3
                                    Я тоже знаю несколько очень классных разработчиков из России. Они наголову выше зарубежных коллег, с которыми я работал, в плане ориентации на создание продукта в том числе. Но по моему опыту, на западе больше тех, кто нацелен именно на релиз (не в ущерб качеству). У нас я встречаю гораздо больше астронавтов архитектуры. Я не против архитектуры, я против говнокода, но должен быть какой-то баланс. Нельзя рефакторить проект вечно и если вы создаете абстрактную фабрику фабрик и кладете ее в IOC-контейнер, а потом настраиваете для нее XML… ну тут что-то не так)
                                      +5
                                      С тем, что на Западе больше профессиональных разработчиков (т.е. разработчиков ориентированных на продукт) я согласен. Мне кажется, что корни этого растут еще из образовательных проектов. В тех же Штатах, насколько я слышал от знакомых, которые там учились, всё направлено на создание совместных проектов, которые, вроде как, почти всегда должны идти в мир, становиться основами для собственных стартапов и так далее. У нас же почти все студенческие проекты заранее приговорены к смерти в конце семестра. Вот и получается, что акцент на то, чтобы сдать зачет / закрыть таск.

                                      При этом сильные компании, в которых есть культура ориентированности на продукт, собирают почти всех сильных программистов. А из таких компаний программисты скорее уезжают за рубеж, чем идут в компании поменьше. Поэтому «культура продукта» распространяется не столько личным примером, сколько статьями на Хабре и других ресурсах.

                                      Имхо.
                                        +3
                                        Воистину!
                                        Априорный приговор к смерти для студенческих проектов, вернее их изначальное ненацеливание на долгосрочное развитие, жизнь и содержание автора — самая расхолаживающая практика в студенчестве.
                                        +2
                                        Тут дело в приоритетах компании.
                                        Есть, например, такое понятие как principle of good enough, а у других — другие приоритеты.
                                      +11
                                      Ну теперь то понятно, почему я почти каждый месяц оформляю им баг-репорт, когда отваливается та или иная функциональность.
                                        +2
                                        А было такое, чтобы через какое-то время после исправления эта функциональность снова не работала? Едва ли) Потому что регрессионные тесты. Короче, я за. На фиг QA — даешь автоматизацию! =)
                                          0
                                          Ну это выглядело бы глупо, если бы они не исправляли баги)
                                          Подобный подход может работать только в случаях, когда деплой можно провести за пару минут (т.е. быстренько сварганить хот-фикс и сразу исправится ошибка) И когда пользователи лояльны (а в большинстве случаев программисты именно такие, ведь «у всех бывает» (с) ) в случае десктоп и мобильных приложений, подобный подход — сущее зло и тут не о чем спорить:)
                                          +7
                                          Теперь вы знаете, что писать надо не баг-репорт, а в твиттер! Тогда у них упадут тесты и они откатят версию =)
                                            0
                                            Ну в поле ввода для текста описания ошибки сказано, что если я уложусь в 140 символов, то они подарят золотую звезду. Так кстати, до сих пор и не подарили ( Я им каждый раз напоминаю «где моя звезда, guys?»
                                          +2
                                          В очередной раз пролили свет на обилие единорогов и пятисотых ошибок. Статья про то, как не надо делать, если хотите получить стабильный и надежный сервис.
                                            +3
                                            Субъективно Bitbucket тоже бывает падает. На сколько я знаю, у них народу меньше. Я не активный пользователь GitHub, и к счастью с 500ыми ошибками не сталкивался. Почему вы пользуетесь сервисом, если не устраивает стабильность?
                                              +5
                                              То, что сервис меня устраивает в целом, не означает, что меня устраивает его стабильность, вроде очевидно. Стабильность гитхаба вообще мало кого устраивает, это его объективный минус, который уже стал притчей во языцех.

                                                +1
                                                Bitbucket работает намного стабильнее и предсказуемее, пользуюсь обоими, поэтому могу сравнивать.
                                                Можно ещё сравнить твиттеры:
                                                twitter.com/bitbucket: последнее сообщение о проблемах 30 сентября;
                                                twitter.com/githubstatus: последнее сообщение 15 часов назад.

                                                Я не к тому, что подход гитхаба неприемлем, совсем нет, и практика это доказывает. Но то, что у них отсутствует QA, и тестируют они на пользователях, активным пользователям очевидно без всяких статей. Просто они осознанно забили на стабильность в обмен на что-то ещё, поэтому если нужен надежный сервис — их подход не вариант.
                                                  0
                                                  Я не покупал платный акк никогда на гитхабе. Есть разница интересно? У них же явно больше одной машины. Есть мнение, что «страдают» бесплатные пользователи.
                                                  • UFO just landed and posted this here
                                              +4
                                              Не понравилось обобщение о западных и восточных разработчиках в конце статьи, правила разработки часто диктуются условиями бизнеса и менеджерами. Подстроиться под них не всегда удается. В моей компании например написание тестов это инициатива прежде всего разработчиков, на это не выделяется время и это никак не поощряется.
                                                +1
                                                А не надо грузить бизнес техническими проблемами. Закладывайте тесты в эстимейт. Это можно написать только за такое время, а если по другому, то все сломается, наш сервис упадет. Мы то на зарплате сидим, нам пофиг, а вот вы деньги потеряете. Бизнес сразу становится лапочкой.
                                                  –1
                                                  Почему не нужно грузить бизнес техническими проблемами? Вот в западных компаниях часто написание тестов отдают на аутсорс например нам. При этом там бизнес учитывает эти проблемы.
                                                  Мы закладываем время написания тестов во время решения задачи, но это позволяет лишь частично покрыть код юнит тестами, а вот модульное и интеграционное тестирование мы пишем нелегально с угрозой получить по шапке.
                                                    +4
                                                    Ну вот представьте, придет директор и начнет рассказывать про проблемы с налогообложением, про демпинг конкурентов, про то что клиент не платит во время. Что отвечают программисты: ну вы же «начальника», надо было предусмотреть, подстраховаться, а я че, я ниче, я код пишу. Так пишите код хорошо. Услуга, разработчиков — написать софт, удовлетворяющий заказчика. Мы — сфера обслуживания, а ведем себя, как девочка-старшеклассница: «ой, кто-же нам с тестами поможет». Да никто, просто возьмите и напишите.
                                                0
                                                Флоу работы гитхаба, судя по всему, вполне допускает ночные релизы. И, в общем-то, на графике это заметно.
                                                  +1
                                                  Про флаги, включающие-выключающие фичи.
                                                  А есть процедура «когда фича устоялась, удалить старый код и флаг?»
                                                    +1
                                                    Вот тут подробнее.
                                                      +1
                                                      Еще есть хорошая стать от Scott Chason Github flow. Мне подход Github понравился больше чем Git-flow, но у них своя специфика — много фич в параллельной разработке и частые деплои.
                                                        +5
                                                        Многие находят Git-flow перегруженным. Я в том числе.
                                                        0
                                                        Стало интересно, а как у них реализуется упомянутый в статье режим фичи «staff-only»? Есть вообще какой-нибудь более или менее стандартный подход к организации «частичной» выкатки фич в Rails?
                                                          0
                                                          Просто в коде проверяется авторизация, если член группы GitHub — welcome, иначе притвориться, что фичи нет. Я не спрашивал как конкретно это реализовано. В asp.net я бы создал атрибут. В Руби же есть мета-программирование, вполне вероятно используются эти механизмы. Короче в любом случае это просто реализовать самому на любой платформе.
                                                          • UFO just landed and posted this here
                                                            0
                                                            Можно на уровне балансировщиков, отправлять либо на один бэк либо на второй по определенным условиям. Это если раскатка на отдельные сервера.
                                                            0
                                                            Огромное спасибо за статью!
                                                            Мне так нравится их методология, что я теперь сомневаюсь, хочу я работать в гугле или гитхабе :)
                                                              0
                                                              <очкарик_mode_on> Непонятно из сообщения в чем именно сомневаетесь. Вы не можете определится где именно хотите работать (гугл или гитхаб) или же хотите ли работать вообще в подобных организациях, в частности гугл и гитхаб. </очкарик_mode_on>
                                                              +1
                                                              Восхищение!

                                                              Я б не стал с наскоку деплоить исправление, в котором чуть отображение данных в html меняется. Правда-правда: если у тебя тысяча пользователей — страшно. Самый безобидный апдейт ни раз приводил к бессонной ночи.

                                                              А тут у вдохновителей явно железная логика, яйца и нервы: мильён мильёнов пользователей и без проблем любой разработчик может что-то там выкатить под присмотром лишь какой-то там автоматики. Суперсистема!
                                                                +1
                                                                Это как раз и культивирует ответственность, что если ты оплошал, то об этом узнают все и сразу.

                                                              Only users with full accounts can post comments. Log in, please.