Интервью с Дмитрием Жемеровым, CTO JetBrains

JetBrains

В подкасте “Разбор полетов” 23 августа вышло интервью CTO JetBrains Дмитрия Жемерова. Читайте расшифровку его первой части в авторской редакции, в которой рассказывается, среди прочего, о почти секретном проекте JetBrains – принципиально новой системе контроля версий.

Всем привет! У нас сегодня гость, и мы будем в основном говорить о компании JetBrains, о ее продуктах, хотя у нас нет такой четкой программы на сегодняшний выпуск. С таким гостем скучно не будет. Дмитрий Борисович, расскажи нам, кто ты такой, зачем ты пришел, кто ты в компании, чем ты занимаешься, немного о себе.

Я работаю в компании уже 10 лет, я пришел разработчиком в проект Omea, был такой RSS-reader (Windows only, к сожалению, это повлияло на то. что он был закрыт). Там не только RSS reader, там еще был news aggregator, и почта, и индексация локальных файлов и еще всякое разное. Потом я стал руководителем проекта Omea, потом, когда Omea закрыли, я пришел в IDEA, потом были всякие разные пертурбации, я начал делать PyCharm, PyCharm – это наша IDE для Python’a, я ее начинал, сам собирал под нее команду, успел в промежутке еще поруководить разработкой RubyMine, и вот не так давно, прошлым летом я получил должность CTO в компании. Я занимаюсь разными вещами, продолжаю заниматься PyCharm’ом, занимаюсь WebStorm’ом, занимаюсь всякими разными внешними партнерствами и контактами нашей компании, вот в частности типа недавнего партнерства с Google, о котором многие слышали, которое заключается в совместной работе над IDE для Android’a, Android Studio.

Да, я думаю, мы тему Android Studio еще подымем не раз, это – интересная штука. То есть ты такой программист, который ушел в начальники, да?

Я на самом деле до сих пор очень много времени занимаюсь программированием, и я не могу сказать что я какой-то глобальный начальник. Должность CTO – это… Ну, понятное дело, когда появляется CTO в компании, где CTO 12 лет не было, это не означает, что он немедленно становится надо всеми начальником и получает немерянные полномочия. Я в каких-то моментах помогаю разным командам координироваться, что-то там согласовывать, но в целом в нашей компании очень плохо с начальниками, поскольку мы очень сильно доверяем программистам и считаем, что программист всегда лучше всех разбирается в той области, в которой он непосредственно работает. Поэтому у нас очень редки ситуации, когда приходит начальник и говорит, что надо сделать вот это и вот так, и человек так точно будет делать. У нас начальник может помогать расставлять приоритеты, или ставить конкретные цели, что нам вот это нужно, или вот это надо отложить. Но у нас в целом очень демократичная структура и достаточно плоская.

А вот по поводу приоритетов. Как вы например решаете, что ту или иную фичу надо сделать, или ту или иную фичу не надо делать? Мы все знаем. что у вас есть такой community центр, построенный тоже на вашем продукте, в который можно submit’ить баги, различные фичи, и пользователи там голосуют за те или иные фичи, вот насколько это учитывается при расставлении проиоритетов?

В первую очередь, что должно быть у фичи, чтобы фича появилась, это человек, который хочет ей заниматься. У нас бывают ситуации, когда какую-то фичу надо сделать обязательно, и мы либо специально ищем под нее человека, либо очень просим кого-то из наших разработчиков за нее обязательно взяться. Но в массе своей если фичей никто не выражает интереса заниматься, и мы не считаем, что это – business critical фича, которую обязательно необходимо сделать, то она может висеть несделанной довольно продолжительное время. А потом появляется человек, которому это интересно, и она может очень быстро появиться. В каком-то смысле у нас даже в этом царит демократия. На votes мы конечно смотрим, и конечно человек, на которого назначена фича, каждый раз, когда за эту фичу голосуют, получает e-mail о том, что за эту фичу проголосовал такой-то пользователь. И после того, как этих e-mail’ов становится 200, их становится сложно не замечать. Там еще люди пишут всякие комментарии про то, как они этого хотят, и что именно они хотят, и это конечно оказывает влияние на ниши проритеты.

А у меня такой вопрос: а часто так получается, что когда vote’s много, но фича ни на кого не назначена. т.е. вы считаете ее не очень интересной? или там баг, а пользователям это критически надо, и они ждут год, даже два иногда?

Такое бывает, но… если скажем фича в бэклоге, и на нее никто не назначен, и за нее все голосуют, то письма о голосах приходят лично мне. Поэтому я это все равно вижу и все равно могу на это реагировать, могу найти человека, поагитировать кого-то этим заняться, или поднять вопрос что давайте мы все-таки это сделаем.Хотя действительно бывают случаи, когда фича, которую много кто хочет, долго остается несделанной. Ну например есть такая фича про поддержку того, что называется collaborative editing или remote pair programming, т.е. люди хотят, чтобы Идея работала как Google Talk, чтобы на двух компьютерах можно было открыть один и тот же файл и его синхронно редактировать, и параллельно что-то делать. Чтобы два человека могли видеть один и тот же файл в одном и том же состоянии и одновременно его редактировать.

Ужас какой

Вот эту фичу очень многие хотят. Есть плагины для Eclipse, которые такое делают, есть кажется для Netbeans.

Для идеи тоже есть

Я вот не знаю.

Сами написали!

Я вот видел, что есть… как же называлась контора… которая делает такие тулы для разных редакторов, они обещали сделать плагин для IntelliJ тоже. [Имелась в виду floobits.com]

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

Да, в этом плане я должен сказать. что у нас довольно распространенный путь попадания фичи в продукт, это когда кто-то пишет third party плагин, который реализует какую-то функциональность, которую мы считаем важной, и дальше мы договариваемся с автором этого плагина, чтобы просто его код включить в код продукта. Если плагин распространяется под лицензией apache2, то это довольно просто сделать, но мы все равно всегда договариваемся с автором, даем ему commit access, если ему интересно продолжать этим заниматься. А если плагин коммерческий, то бывали случаи, что мы плагин покупали. т.е. лицензировали код и так далее. Если фича нужная, если она хорошо сделана в third party плагине, то он может попасть в продукт. Вот последнее, что мы взяли из community, это поддержка…. есть такие javascript’овые новые темплейтные языки HandleBars и Mustache (это два диалекта примерно одного и того же языка), был хороший плагин, который это поддерживал, и мы его включили в 7-й WebStorm, и соответственно в IDEA он тоже появится в каком-то виде.

А вы, когда его включаете, вы его покупаете? Или вы надеетесь на то, что оригинальный разработчк будет его дальше поддерживать?

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

А вот при выборе насколько помогает статистика. которую собирает IDEA и репортирует вам обратно, насколько она помогает выбирать, что подкрутить, что улучшить? Может быть какую-то интеграцию. с какими-то серваками и так далее?

Скажем так: наверное не настолько. насколько бы мы хотели. В каких-то вещах мы смотрим. Какие-то решения безусловно принимаются на основании статистики. например, сколько процентов пользователей идеи пользуется Python’ом, или сколько пользователей пользуется фичами database, или сколько пользуются тем или иным фреймворком. Еще один показатель, на который мы смотрим – количество download’ов third party плагинов.
То есть если мы видим, что какой-то плагин много народу качает, для нас это повод подумать о том, не хотим ли мы это в продукте получить. В целом там есть много информации, которую мы пока не умеем достаточно хорошо обрабатывать. Но у нас недавно сформирован отдел аналитики, одна из задач, которая перед ним стоит – извлечение пользы из всей этой информации, которую мы собираем через статистику.

Здорово! А какой плагин сейчас самый популярный?

Из third-party или из…?

Давай по обеим категориям, можешь сказать?

Из наших Scala, конечно. Но Scala мы намеренно не включаем в дистрибутив, потому что она развивается быстрее, чем базовый код, и нам не хотелось бы, чтобы апдейты Scala-плагина выходили только раз в год вместе с свежими версиями идеи. И нам удобнее, чтобы она была отдельно. Я смотрю, что из third-party плагинов на первом месте JRebel.

Хей-еей! [слышен веселый возглас разработчика JRebel]

Да, приятно :)
На самом деле это совершенно оправдано, это – очень хорошая и полезная фича. Мы ей почему-то не пользуемся, мне очень сложно ответить на вопрос «почему?», но почему-то не пользуемся.

Давай немножко тронем Android Studio. Как так получилось? Это вы пришли к Google и сказали, что вы можете сделать, или они пришли к вам и сказали, что мы посмотрели, как у вас клево работает community edition со всеми печенюшками, и у вас есть Android Plugin, а сделайте нам так же, только чтобы была кнопка большая и сделайте нам красиво?

На самом деле они к нам пришли. Там смешная история была: они к нам пришли, что-то мы с ними обсудили, какие-то варианты сотрудничества рассмотрели, потом они куда-то пропали, и в этот момент появляется новость, что Google становится официальным партнером Eclipse Foundation. Мы думаем: ОК, значит, с нами что-то не получилось, не договорились, все значит, Eclipse будет рулить.Потом я на Devoxx’e прошлогоднем встречался с Xavier Ducrohet, который ведущий разработчик инструментария Android’овского, он говорит: «да нет, это все про Eclipse к нам абсолюно не относится, и вообще Eclipse нас страшно задолбал, и нам бы конечно хотелось иметь другую платформу для наших инструментов.»В общем, дискуссии потом продолжились, и мы в итоге сошлись на варианте, что мы сотрудничаем на базе open sourc’ного code base IntelliJ Community Edition, и просто делаем продукт. Я считаю, это интересный case, что сотрудничество с компанией Google – такой большой серьезной компанией – JetBrains, которая не такая большая, но тоже достаточно серьезная компания, при этом вокруг Android Studio не было подписано ни единой бумажки, не было заплачено ни цента денег ни в ту, ни в другую сторону. Это чистая success story open source, поскольку у нас есть Apache лицензия, то все условия нашего сотрудничества в Apache-лицензии прописаны. Дальше мы можем в порядке доброй воли нашу поддержку им оказывать, поскольку нам это все интересно, они могут в порядке доброй воли звать нас на Google I/O и там дать нам возможность о продукте что-то рассказать, но это все без каких-то обязательств, без каких-то требований, условий расторжений, мне кажется, это очень круто.

Слушай, а как это фактически происходит? Они эту Android Studio делают сами, но используют code base, который они получают из open source репозитория?

Технически это происходит так: мы разбили код community edition на два разных git-репозитория: в одном community edition сам по себе, в другом – собственно Android, все, что относится к Android’y. Репозиторий CE мы сами девелопим, у них есть своя копия и того, и другого репозитория, и из CE они вытаскивают изменения к себе. Android-репозиторий они девелопят в первую очередь сами, и мы вытаскиваем изменения от них. То есть мы сами тоже что-то делаем, доделываем какие-то фичи, которые мы договорились, что удобнее нам сделать, делаем какие-то большие рефакторинги, которые затрагивают весь code base c Android-плагином. Но основное направление движений – это от них к нам. И пока что это довольно хорошо работает.

Ну да, это очень классная штука, потому что когда-то когда я начинал лезть в эту воду с андроидом, смотреть на какие-то тулы, мы делали страшные вещи. Мы компилили flex в андроид – в Adobe Air для андроида – там нужен был SDK, и поэтому я в tooling тоже смотрел. И когда появилась поддержка в IntelliJ IDEA это некисло порадовало меня, потому что как работает например если мы говорим о flex’a, я очень долго этим занимался, и по ходу дела людей очень сильно задалбливает flash builder, который является IDE под этот flex, под это дело, и вот я пару недель назад мы мигрировали один очень большой проект под IntelliJ IDEA, и она как-то умнее работает с файлами, не дергает компиляцию каждый раз, когда сильно поменялось, и потом не перестаривает это все свои инджексы, как в Eclipse’e, потому что в Eclipse’e это дольше все получается. Из-за того, что Adobe собаки знают немножко больше чем они дают в open source, во всяком случае знали, нет, tooling у них сейчас не open source’ный, они же делают как: у них есть свой компилятор, который работает внутри flash builder’a, а тот компилятор, который лежит в SDK, он немножко другой. IntelliJ IDEA умеет работать очень хорошо, она умеет работать и с SDK-шным компилятором, и еще с каким-то хиттрым компилятором, который назвается по-моему flash shell, что то в этом роде, он типа делает прогретую VM-ку, короче, такие крутые штуки, которые есть в IntelliJ IDEA, я не знаю, когда они появятся в Eclips’e. Это такой мой крик души.

Если говорить о flash’e, надо признаться. что мы там ковырялись довольно глубоко, т.е. мы патчим какие-то класс-файлы xml-ного компилятора, чтобы там что-то фиксить, я не знаю деталей, но я знаю. что у нас есть патчи для MXML-фиксов в составе нашего code base. И у нас написан свой декомпилятор этого ABC, байт-кода виртуальной машины Adobe’вской. Короче, там было вложено много усилий, чтобы это работало так, как оно работает.

Да, вопрос стоит поставить таким образом: вы будете продолжать поддерживать эту странную платформу, которая называется Adobe Flex, и теперь она называется Apache Flex, и какие ваши дальнейшие планы по поводу этого? Будете ли это продолжать?

Мы в какой-то момент даже хотели делать отдельный продукт. Он успел даже появиться, появился EAP для него, он назывался Astella, и была команда, которая его писала, мы в это довольно серьезно вкладывались. В какой-то момент, когда у нас уже был готов план на релиз, прогремел анонс, что Adobe внутри себя разработку Flex’a заканчивает и передает это в community, и теперь это Spoon Project. Мы на это все поглядели и с грустью признали, что кажется с продуктом мы опоздали и нужно переносить функциональность, которая в рамках этого продукта была разработана, в состав IntelliJ IDEA, что и было сделано. Вся эта тема с flash build конфигурациями, это все изначально писалось в рамках Astell’ы, и отличалось от того, как это выглядело в flex плагине в IDEA, и потом это все было перенесено и смержено. Насчет дальнейший инвестиций: у нас сейчас есть один разработчик, который full time занимается поддержкой Flex, Flash и вот этого всего, и пока что мы планируем так и оставить. Он будет продолжать этим заниматься, какие-то новые фичи появляются, но более крупномасштабных инвестиций не планируется.

Понятно.

Я еще хотел бы вернуться еще на шаг назад по поводу того, что в Eclipse все плохо, я хочу отдать дань уважения коллегам, потому что мы с самого начала, еще до того, как это все началось, были очень высокого мнения о том, как был сделан eclips’овский tooling для Android. Те люди, которые его делали, они очень круты, там например есть такой не безызвестный в community Tor Norbye (есть такой подкаст JavaPosse, про который тоже все знают, он давний его участник) – собственно он работал сначала в Sun’e и писал плагины для NetBeans, т.е. он делал поддержку Ruby, потом делал поддержку Python’a какое-то время, потом перешел в Google и писал tooling Andoid’овский для Eclipse, и теперь пишет Andoid’овский tooling для IntelliJ IDEA. Это наверное единственный человек в мире, который имеет настолько обширный и пространный опыт писания плагинов под все три основных IDE, и он реально очень крут. Это я к тому, что мы знаем, что после того, как мы отдали поддержку Andoid’a Googl’у, она будет реально в хороших руках, там все будет хорошо, и она не будет хуже качеством, чем те фичи, которые мы сами девелопим в рамках IntelliJ IDEA. Короче, все будет хорошо. Вот.

Клево! Так я про flex просил. У меня коллеги просили: к тебе тут приходит человек из JetBrains, спроси у него про flex: как там дальше будет?Давай немного тронем тему, которую ты уже затронул: как в Идее можно парно программировать. Почему меня это зацепило, потому что я слышал этот же посыл в одной из презентаций вашего будущего интересного проекта, о котором все говорят, никто не знает, что это такое, но все говорят.

Да, мы тут делаем систему контроля версий.

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

Я попробую. Я сам к разработке этого проекта не слишком причастен. То есть я конечно в курсе, что мы делаем и зачем, но я не уверен, что я смогу на все технические вопросы ответить. Но я попробую. То есть собственно message в том, что это такой специальный version control с dropbox. То есть это VC, который постоянно хранит на сервере mirror вашей рабочей копии, постоянно синхронизировано со всеми компьютерами, с которыми вы работаете, и за счет того, что состояния кода постоянно публикуются на сервер, это дает массу прикольных возможностей по тому, чтобы совместно работать над кодом с какими-то другими разработчиками.В обычной системе контроля версий файл может быть фактически в двух состояниях: либо он локально поменян, и не отдан никуда, либо, соответственно, он закоммичен и отдан всем в систему контроля версий. Распределенные системы контроля версий типа git, mercurial добавляют к этому еще несколько состояний, соответственно, файл может быть закомичен, но не запушен, либо может быть запушен в общий репозиторий, и тогда, соответственно, все могут его взять. Либо есть еще разные сценарии, при которых вы пушите файл в свой репозиторий, а потом с вас его pull-ят тем или иным образом, когда нет центрального репозитория, то, соответственно, изменения притягиваются по более сложной топологии, с одного разработчика другому. В конечном итоге есть один мейнстрим, который всем доступен.

То есть, фактически, это не распределенная система, правильно?

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

То есть вы скорее расширили систему в сторону code review, чем в сторону хранения сорцов. Это такой Gerrit получился.

Ну нет, я бы так не сказал. Про code review я могу рассказать отдельно, это отдельная часть нашей истории, это не совсем для code review, именно для каких- то таких сценариев совместной разработки скорее.

А оффлайновые коммиты поддерживаются в этом сценарии?

Да, на самом деле, говорить о том, что наша новая система контроля версий, она централизованная — не совсем правильно, т.е. там на самом деле локально поднимается сервер, который такой же точно сервер, как центральный репозиторий и, соответственно, вы можете, не имея связи с центральным сервером, все коммитить локально и потом, подключившись к центральному серверу, вы можете синхронизировать в обе стороны. И этот же локально поднятый сервер является интерфейсом для системы контроля версий. Большинство стандартных систем контроля версий ориентированы на интерфейс командной строки как, например, git и mercurial, соответственно, есть какие-то бесчисленные опции, которые поддерживает интерфейс и так далее, а в нашем случае основным интерфейсом для работы системы является веб-интерфейс, поднятый на локальном сервере. То есть у вас есть веб-интерфейс, который красивый, современный и со всеми rich-клиентными технологиями разработки, и он дает вам очень удобный способ выполнять все необходимые операции. Интерфейс командной строки тоже поддерживается, но он не является основным, не является тем, что мы в первую очередь предлагаем как средство работы с системой.

Понятно, ну, я т.е. хотел спросить, как все это дело будет интегрироваться с каким-нибудь Jenkins’ом, ой сорри, сорри, сорри… с TeamCity. Или с TC будет изначально какая-то своя поддержка зашита?

Зашито ничего не будет. Понятно, что есть какое-то API; это все, на самом деле, пишется на Java и будет какое-то Java-вское API (клиентская библиотека), с помощью которой можно будет написать интеграцию с тем же Jenkins, TeamCity, с той же IDEA или Eclipse. Или можно, конечно, через интерфейс командной строки делать, если по какой-то причине Java-вское API не подходит.

Ты сказал, это все т.е. на Java написано, т.е. внутренний сервер это все на Java?

Да.

Ого! Возникает вопрос: а почему не Kotlin?

На самом деле там Kotlin используется, т.е. там есть куски кода, написанные на Kotlin.

Ну, Kotlin мы тоже сегодня немножко "тронем".

Да, я готов ответить про Kotlin.

Смотри, та схема, которую ты объяснил, напоминает мне такую штуку, ты наверное знаешь, как Rational Team Concert от IBM, Jazz и иже с ними.

Я знаю о ее существовании, но, честно говоря, никогда руками не трогал.

Ну, в принципе, насколько я ее трогал, смысл этой системы очень близок к вашему: ты тоже можешь заводить себе stream-ы у тебя тоже есть workspace-ы, которые сервером синхронизируются, насколько эти stream-ы можно шарить между девелоперами в этом RTC. Но в остальном все так очень похоже; у них, кстати, тоже нет интерфейса командной строки, у них ставятся какие-то свои специальные плагины, причем (собака!) еще и денег за них просят.

Ну это же IBM, должны же они как-то зарабатывать на софтвере. И вот поэтому, когда я смотрел эту презентацию, это все выглядело очень так знакомо и похоже. Ну, опять же, если ты не работал, ты не можешь это прокомментировать, но it’s okay. Такая отсебятина, мои мысли вслух.

Я, честно говоря, даже не знаю, смотрели ли люди, которые это придумали, а это в первую очередь Олег Степанов — один из наших нынешних co-CEO, который весь этот проект придумал и драйвит его. Я даже не знаю насколько он смотрел на RTC. Я могу у него это спросить в следующий раз, когда увижу его.

Ясно. Понятно. Ты говоришь, что эта функция будет похожа на Dropbox. Можешь прояснить?

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

С моей точки зрения, эта идея… Опять же – идея… :) Эта концепция, которая позволяет уйти тебе от низкоуровневых абстракций таких, как файл, как мета-данные, это вот хорошая идея, это то, по-моему, куда должны двигаться современные системы контроля версий. Мы уже должны давно уйти от этих странных архаичных абстракций, которые называются там файлы, папки и т.д. Т.е. должны быть какие-то более высокоуровневые инструменты что-ли, опять же, это мое мнение, и тот же Dropbox как раз тоже нас научил, что документы можно и прозрачно синхронизовать. А как конфликты будут разрешаться в этой ситуации?

Будет merge-UI, т.е., собственно, уже есть какой-то UI, который позволяет резолвить конфликты.

Будет ли такая возможность, если мы шеирим эту функцию с другим разработчиком, сможем ли мы, например, одновременно редактировать один и тот же участок файла?

Этот вопрос, на самом деле, — вопрос скорости синхронизации. Я, честно говоря, не готов ответить, там сейчас реализовано таким образом, что сервер получает нотификации об изменении файлов в локальной файловой системе и, когда он видит изменения, он их синхронизирует. Грубо говоря, если вы печатаете в IDE и не нажимаете кнопочку save, то без какой-то дополнительной интеграции эти изменения сами (синхронно, автоматически) не подхватятся.

Подожди-подожди, кто нажимает кнопку save тогда в IDEA?

Оно сохраняется в определенное время. Это очень больная для нас тема про save. Он происходит в какие-то определенные моменты времени и, если не предпринять никаких дополнительных усилий и написать плагин, который будет интегрироваться, то этот save будет происходить на деактивацию фрейма. А это слишком редко для данного сценария.

Я понял. А вообще, опять же, вот эта концепция save-а, я считаю, какая-то архаичная и попользовав долгое время IDEA с этой функцией я, опять же, как-то ловлю себя на мысли, что я забываю сэйвиться в Eclipse. Т.е. потому что приходится — я не один же такой работаю, у меня коллектив, а в коллективе распространенная IDE — эта Eclipse. Чертовски удобная фича — это local history, если что-то не в тот момент сохранил, всегда можно откатится. В Eclipse, кстати, тоже есть. Но надо сохраняться.

Local history, по-моему, есть во всех IDE сейчас.

А сама идея вот этой VCS она, как бы интуитивно подразумевает, что у кого-то внутри компании возникла подобная нужда в синхронизации? Как будто упор на синхронизацию в этой идее происходит. Это действительно так?

Я не стоял у истоков настолько близко, чтобы вот это вот прояснить. Да, видимо, нужно пояснить, что мы, конечно, планируем это все выпускать в open-source. Делать систему контроля версий, которая не будет open-source — это просто немножко нереально в наши дни.

Но IBM же делает.

IBM делает, но IBM — это IBM.

Исторические причины скорее.

Да, т.е. бизнес-модель здесь, очевидно, это хостинг, который мы хотим предлагать для этой системы. Ну, и, опять же, интеграция, какие-то там плагины, все такое. Да, и еще нужно упомянуть: это все очень хорошо интероперируется с git-ом, т.е. сейчас вся эта система, когда начинала писаться, работала, как некоторый layer поверх git-а. Т.е. вот, собственно. есть история до какого-то момента в git-е и есть state – то, что произошло после последнего коммита в git-е и то, что трекается нашей системой. И потом, когда вы нажимаете кнопку publish в нашей системе, это появляется в виде коммита в git-е. И, соответственно, есть сценарий, когда вам не обязательно продавать эту систему всей команде сразу, у вас есть git в качестве центрального репозитория, т.е. вы знаете, что git работает, что у вас не будет data-corruption-а, у вас не будет каких-то проблем с несовместимостью с другими тулами и при этом вы все равно можете наслаждаться бонусами этой системы в качестве надстройки поверх, т.е. там какие-то фичи при этом работать не будут. Я, к сожалению, не могу совсем подробно ответить, но, в принципе, такой сценарий работает.

Главный вопрос. Когда?

Мы над этим работаем. К сожалению не могу сказать про сроки. Я довольно давно не выяснял текущий статус. Перед тем, как кому-то это показывать, мы планируем начать использовать это внутри компании, т.е. один из проектов полностью перевести на это в качестве основной системы контроля версий. Пока это конечно self hosted, т.е. сама команда сидит уже на этой системе контроля версий, но никто другой ей не пользуется.

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

Понятно. Дмитрий, вопрос. Во-первых, ты сказал, что эта система обратно совместима с git’ом. Так?

Нет, «обратно совместима» – это не то. Она интегрируется с git’ом.

Т.е. например если есть какой-то репозиторий на github’e, я могу этой гипотетической системе сказать «вот, возьми вот этот репозиторий» и работать через вашу систему с дополнительными коммитами с обычным репозиторием?

Насколько я понимаю, да, это можно будет делать.

И тогда я честно говоря не понимаю, кого вы видите своим конкурентом? Вот есть на рынке такие системы контроля версий, которые в open source, git, например, есть системы, которые больше применимы в enterprise, вы для себя видите как, это для кого, кто ваш основной конкурент?

Скажем так, на самом деле с git’ом такая ситуация, что с одной стороны у git’a набрана такая масса, что это просто глупо отрицать значимость git’a и github’a для современной индустрии, против этого не попрешь. И понятно, что для разработчика open source проекта, который принимает решение, какую систему контроля версий использовать, у него есть очень сильные аргументы не выпендриваться, сесть на git и на github, и там вся инфраструктура, и все community, все потенциальные contributors знают, что с этим делать, и т.д. Но при этом мы абсолютно не считаем, что git – это вершина совершенства систем контроля версий, и что ничего лучше, чем git, сделать невозможно. Т.е. у git’a очень много своих идиосинкразий, у него такая своеобразная модель, которая поддерживает операцию rebase, и есть очень много людей, которые считают, что операция rebase не должна существовать в принципе в системе контроля версий, не должно существовать возможности переписать историю.Поэтому мы хотим попробовать сделать что-то свое, что с какой-то другой стороны посмотрит на всю эту проблематику и может быть даст какие-то новые толчки к развитию этой всей отрасли. Может быть, найдет свою аудиторию в первую очередь среди enterprise разработчиков.Если говорить об enterpris’e, то очень большой недостаток, от которого мы реально страдаем в том, что касается git’a, это то, что в нем нет никакой гранулярной системы пермиссий. Если у вас есть доступ к git’овскому репозиторию, у вас есть доступ ко всему, что в этом репозитории лежит. И нам было бы очень удобно каким-то нашим партнерам давать доступ на чтение к каким-то кускам кода IDEA, не давая доступа к полному source code. И сейчас мы не можем этого сделать, мы там в итоге посылаем diff-файлы по почте или какой-то такой подобной ерундой занимаемся, в XXI веке даже стыдно в этом признаваться.В частности, проблема пермишнов в нашей системе контроля версий тоже будет поддержана тем или иным образом.

Хорошо, а такие проекты как Gitflow, это как-то включается в вашу систему? Какое-то workflow по управлению исходниками, если вы говорите у вас там есть code review, какие-то зачатки… Это как-то согласуется? Есть какое-то workflow, которое используется в IntelliJ, вот мы там берем вот это, есть QA, есть фичи, есть бранчи, и вот это вы все привнесли в свою систему.

Я бы так не сказал. Прежде всего, в IntelliJ очень простой workflow, мы например, не … Я могу отдельно некий rant про это рассказать. Я считаю, что feature branches – это зло, и ими пользоваться – это неправильно. Я могу, если интересно, раскрыть свою мысль.

Вполне.

Когда я пишу какой-то продукт, для меня очень важно, чтобы та работа, которую я делаю, была частью продукта, и с этим самым продуктом постоянно была согласована. У нас в команде YouTrack в некоторые моменты так интересно этим пользовались, что у нас реально были feature branch’и, которые … грубо говоря, в релиз запланировано N major фич, для каждой фичи есть свой feature branch. И вот в этом feature branch’e бегают тесты, билды из этого feature branch’a берут QA и начинают тестировать, и потом очень боятся того момента, когда из этих трех feature branch’ей нужно будет собрать продукт и выпускать релиз, потому что релиз, понятно, будет из одного branch’a, а не из трех разных. То есть это – некий экстремальный случай, понятно, что тут до такого доводить не обязательно, но мне кажется, что вообще continuous integration – это очень хорошая и правильная практика. И можно просто прочитать все тексты, написанные, когда она появлялась, почему это хорошая и правильная практика. И feature branch’и на этой практике ставят крест, потому что integration у нас не происходит continuously, а просиходит в какие-то моменты, раз в неделю или там когда вы закончите работу над feature branch’ем и его merg’ите.Да, я поясню, что это все не касается короткоживущих feature branch’ей, если там FB живет в течение нескольких часов или пары дней, то в нем ничего плохого нет, конечно же. Но просто я вижу, что это реально начинает выгдлядеть не так, и начинает девелопиться фича очень долго в каких-то отдельных веточках, и мне кажется, что это – зло.

Насколько я помню, TeamCity из коробки позволяет feature branch’и собирать, и делается это по-моему то ли клонированием, то ли копированием конфигурации.

Это правда. Но то, что в TeamCity есть поддержка feature branches, не означает, что это является хорошей практикой.

Каждый имеет право на ошибку и каждый имеет право на собственное мнение.

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