Comments 229

Я правильно понимаю, что это аналог Team Foundation Server от Microsoft. Вроде бы там есть почти всё то же самое?

Да, Azure DevOps Server — наш конкурент. У нас ещё есть чаты и team directory.
В Space есть много фич, аналогичных GitLab, и даже больше. Но сравнительной таблицы пока нет.
Функционала больше чем в GitLab кмк.
Хотелось бы попробовать Space.
Тем более, что я пользуюсь уже продуктом одним из продуктов JB.
*комикс_о_14_стандартах.jpg*
*анекдот о том, что очень нужны были деньги*
Потому что интеграция — это опять то, откуда мы пришли. Мы хотим создать не набор инструментов, а один инструмент.

… но со вренем выяснится, что ту же Jira всё равно не догнать ни по функционалу, ни по масштабам интеграции со всех сторон, так что вариант "всё своё, а таски — в Jira" уже не будет казаться таким дурным… а значит нужна интеграция с Jira, а там и… ой, где это мы?

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

Джирой очень неприятно пользоваться. Такое ощущение, что дизайнеров у них нет.
У меня в последнее время ощущения ровно обратные. Atlassian нанял миллион главных дизайнеров, и они никак не договорятся между собой как лучше сделать. Уже устал решать ребусы «а найди-ка на странице то, что было вот здесь ещё на прошлой неделе, а теперь оно неизвестно где».
Осталось только прикрутить саму IDE в эту платформу и можно будет работать прямо из браузера :).
а что насчет интеграций с GitHub, Resarper? Или гитхаб тоже ваш конкурент получается?
Скорее всего, такие интеграции можно будет писать самому. Но вообще, главная мега-идея Space в том, что это одна экосистема с бесшовным опытом использования всего внутри неё. В этом смысле, интеграции делают это опять зоопарком. То есть, они будут возможны, но мы считаем, что в итоге лучший вариант — использовать всё внутри Space.

Я пишу разные проекты и иногда хочу открывать репозитории для внешнего участия. На гитхабе я просто делаю репу публичной.


Здесь получается, всем участникам придется зарегистрироваться в Space и возможно даже вступить в мою "команду"?

К примеру в Phabricator можно настроить зеркалирование репы в публичный источник. Основная разработка идёт в Phabricator, а уже сама система пушит во вне. Есть конечно вопрос с PR и Push-request-ами, но кажется их вполне можно либо забирать напрямую из GitHub интеграциями, либо обрабатывать отдельно в рамках дополнительного бизнес-процесса. Кроме того, эта приблуда не для людей, которые ведут свою разработку публично, просто некоторые репы скрывают от любопытных глаз. Подобные системы разворачивают те, кому каждый коммит в публичную сеть нужно согласовывать с ИБ и парой других отделов. Публичную разработку сложно вести в платном сервисе, тут с GitHub мало кто может тягаться…
Ну вот куча интеграций, а выше говорят, что делайте всё внутри Space )
Atlassian, Microsoft имеют очень универсальные платформы, но все всеравно пользуются гитхабом и облачными CI по типу appveyor и вашей же Teamcity (я сейчас не про компании, а как раз про мелкие команды). Ваши продукты шикарны, но представленная штука без интеграций — это пузыри команд :) без особого взаимодействия.
В Space есть зеркалирование репозиториев. Можно сказать, что репа в Cпейсе — зеркало репы на Гитхабе. Коммитить можно и туда, и сюда одновременно.
Коммитить можно и туда, и сюда одновременно.

Что-то? Расшифруйте? Потому что очевидно, что если будет бардак и разрабы будут коммитить в оба репозитория, то вы потом замучаетесь конфликты лечить (ибо синхронизация никогда не бывает мгновенной, а только лишь eventually). Итого — мы приходим к тому, что какая-то репо будет read-only, а вторая — master, либо как-то строить конвенции по веткам.

Оба репозитория read-write, но действительно, оригинальный репозиторий является «мастером»: когда вы пушите в зеркало, мы сначала пушим в «мастер», и убеждаемся, что пуш прошёл. Это прекрасно работает.

За всех вы, конечно, перегнули палку, слегка.
Количество пользователей Atlassian(а это не только JIRA) и TFS — очень велико.

Чтобы использовать «всё внутри Space» не хватает mercurial :)

Да знаю, знаю — «им никто не пользуется».
Да ладно, CVS не так уж и плох.
По сравнению с «ProjectName_ver1488_22.8.19.zip».
И способов накосячить сильно меньше, чем в гите)

Получится комбайн. Девиз любого комбайна — "все, сразу, но нифига толком".
Зачем?

Это оно и есть, просто закрытый вариант потыкать :) Отправьте заявку, Вам ее одобрят очень быстро.
Отправьте заявку, Вам ее одобрят очень

Видимо, только если вы большая компания.

Отправил заявку в день выхода статьи (пятница), письма с инвайтом пока нет.
Наша компания подписана на продукты JetBrains, периодически репортим баги, как минимум один был признан критическим (в Resharper). Пользуемся TeamCity.
Однако инвайта пока нет…
Интерес к продукту и правда очень большой. Если Вам пока не ответили, это скорее всего связано с тем, что заявку просто еще не обработали. Процесс может занять какое-то время.
Мы все ещё в процессе обработки заявок. Подскажите, пожалуйста, какого числа вы заполняли форму?
Очередная платформа, которая хочет интегрировать все в себя?

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

Мне одному кажется что это направление уже доказало свою бесперспективность?

PS я ожидал ИДЕ для управления серверами, доступами, облаками и прочим девопсом, навороченная консоль. Как датагрип для ДБА только для девопсов.

Jenkins не хостит внутри себя гит.


Мне одному кажется что это направление уже доказало свою бесперспективность?

Бизнес хочет единое решение, с возможностью заплатить в одно место и больше не иметь головной боли.

> Jenkins не хостит внутри себя гит

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

> Бизнес хочет единое решение

ни разу не сталкивался на практике. Даже покупатели SAP стараются оставить что-то не из продуктов САПа.
Бизнес хочет единое решение, с возможностью заплатить в одно место и больше не иметь головной боли.

Минус таких решений в том, что они более скудны в функциональности, чем отдельные проекты. А попытка затащить весь функционал чаще всего приводит к появлению ещё одного неповоротливого монстра
На практике есть тысячи примеров, когда этот монстр даже не смог начать работать
Это такой же спор как и «микросервисы или монолит». Точно так же как с продуктом, это справедливо и для внутренних процессов. Если у вас небольшая команда разрабов, то вам наверное хватит комбайна вроде гитлаба, но когда количество разрабов перевалило за сотню, процессы стали сложными и запутанными, эффективнее разбить всё на компоненты + часть инструментов вообще написать самостоятельно.

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

Тулы от разных вендоров = много вендор-лока плюс постоянно ломающиеся интеграции. То-то во многих Энтерпрайза побеждает атлассиан стек (конфлю, жира, битбакет и бамбу)

В этом как раз и проблема. Все те, кто участвует в разработке вынуждены фокусироваться на разных инструментах (коих стало миллион). Лично мне было бы удобно начинать свои рабочий день в одно месте, где есть всё необходимое.

Теперь остается узнать насколько Space будет удобна в использовании (по коммиту протестировалось/отдеплоилось/откатилось/оповестило при фейле/выкатилось по записи в каледаре) и т.д.).

я поэтому и думал про возможность внедрить phabricator в отдельно взятой организации — как решению полного цикла.

> Лично мне было бы удобно начинать свои рабочий день в одно месте, где есть всё необходимое.

я понимаю как никто другой. Однако это не работает на практике. В каждой команде свой стек. Как верно заметили, приложений куча и все они пересекаются. Вместо выработки стандартов и клиентов — чтобы каждый разработчик выбрал себе клиент по вкусу. Мы продолжаем получать все новые, несовместимые со старыми, пузыри.

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

Дичайшая жиза.
С теплотой вспоминаю свою систему в 2012 году — ВКшечка, аська, фейсбук в айчате, интегрируются нативно в ОС, разве что скайп для периодических переговоров, ну и фидо кроме терминала никак. Сайты все подвязывались в Reeder. Календари расшаренные и прочее офисное барахло подвязывалось в системный органайзер. Браузер по итогу был практически не нужен.


А теперь каждому подавай или вкладку браузера, или новую прилагу, которая зачастую тоже браузер. Интегрированные в ОС тулзы ни к чему не подходят, если не хочешь сидеть исключительно в разжиревшей кастрированной экосистеме вендора. Ибо чем дольше ты сидишь в "продукте", тем больше денег приносишь, а если ты тупо к нему по XMPP цепанулся и не любуешься на продукты жизнедеятельности дизайнеров — как же писать твои повадки для продажи и втюхивать рекламу взамен?

Очень круто использовать интегрированные в ОС нативные фичи вроде месенджеров, заметок, календаря и прочего, когда у вас в организации у всех одна ОС стоит. Просто в командах кто-то на маке сидит, кто-то на винде, кто-то на убунте к примеру и использовать для работы нативные для ос приложения не представляется возможным. Именно поэтому так выстрелило облако и тот же электрон.
Поддержу vladkorotnev раньше же как то получалось. Были отдельно продукты, отдельно операционки и отдельно клиенты. И ты себе выбираешь каждого их трех по своему вкусу. Проблемы «писать больше кода для разных случаев» не стояло. Потому что делая новый продукт — ты поддерживал старый (в 95%) стандарт и оно работало на старых клиентах.

А теперь «только я умею писать клиенты для своего облака» — и хоп. Выбор уже не стоит не то что в клиенте — а даже в операционке. Все есть веб.

Веб (конкретно приложения в вебе) обещал нам невиданную свободу. А на практике ее только уменьшил.

Веб-приложения обещали свободу не нам, а бизнесу. И бизнес её получил — шлёпать одноразовые апи и выкатывать приложения на скорость, чатики с потреблением ресурсов от видеоредактора и всё в этом духе, и никто ему не мешает.

Так вот это и решалось тем, что были стандарты, а не апишлёпство. И любая операционка/софтина прикручивалась к соответствующему сервису вне зависимости от.
Та же ВКшечка ничего специального не делала чтобы поддерживать мою Макос, но она работала.

Не понимаю о каких стандартах вы говорите (можно пример?), но что нам «говорит» реальность:

CS развивается семимильными шагами, инструментов очень много. Если в условном начале 2000-х их было совсем мало, то теперь проблема выбора продукта встала в полный рост. Какие стандарты могут появляться в столь динамичной среде? Насколько они будут актуальны, кто будет владелец и в какой стране они будут приниматься, какие гарантий развития и взаимодействия с сообществом?

То есть, если договориться по поводу протоколов трансграничного сетевого взаимодействия и геометрии шлюзов МКС мы еще как-то можем, то принимать какие-то стандарты в крайне динамичной среде со множеством участников — затея абсолютно нежизнеспособная (собственно, мы это наблюдаем сейчас).
en.wikipedia.org/wiki/Language_Server_Protocol как отправная точка


PS я ожидал ИДЕ для управления серверами, доступами, облаками и прочим девопсом, навороченная консоль. Как датагрип для ДБА только для девопсов.


Я начинаю понимать. Вы спроецировали свои желания иметь универсальный инструмент для разных вендоров, чтобы всё это было удобно/бесшовно.
Не буду повторяться — это не отвечает реальности — перечитайте мой комментарий выше.

PS. Сам я буду использовать того вендора (платить ему деньги), который даст мне наиболее удобный инструмент. Ждать, когда появится «универсальный универсал» с поддержкой всех и вся — не намерен.
я сомневаюсь что когда либо будет существовать один инструмент для управления всеми.

Я никого не агитирую использовать Х.

Я агитирую индустрию, чтобы у программистов был выбор. А то сейчас приходишь на проект и оказывается что у тебя даже нет выбора в ИДЕ. Потому что инструменты разработчика (существенно ускоряющие производительность) уже написаны под конкретную ИДЕ.

PS год назад я столкнулся с гитлабом, который не видуе больше 5 лет. С одной стороны я горд за ребят, что они смогли сделать такой прыжок в функционале. С другой стороны я не хочу ставить гитлаб на свои проеты — потому что я знаю что мне нужны месяцы чтобы разобраться в их функционале. В функционале, который я и так умею делать, но на более простых инструментах.

вы можете придти на проект и написать свои инструменты для разработчика под свою любимую IDE. И поддерживать их (инструменты) потом дальше.
Но гораздо выгоднее заточиться под конкретную, выбранную командой, IDE и не распыляться на зоопарк остальных.


Аналогично и с выбором ОС в компании — зоопарк надо поддерживать кому-то. Либо вы делаете сами, без ущерба для основной рабочей деятельности, либо аргументируете работодателю, почему он должен оплачивать эти часы админам, либо платите админам сами.

Видимо у Вас не бывает двух проектов подряд или частой их смены. Или домашних проектов.

PS если бы админы решали мои проблемы — я бы платил. Уже полгода жду настройки сети вместо VPN.
Я всё ждал, кто же раньше — вы или яндекс — запилит свой посконный гитхаб с блэкджеком и канбаном. Особенно после санкций гитлаба.
Интересно будет посмотреть.
Да при чём здесь внутреннее пользование? У многих «Вась» тоже есть своя приватная гит репа с каким-нибудь редмайном/гитлабом/… на впске.
Ну, публичный функционал их коннекта явно не дотягивает до представленного выше.
это означает, что self-hosted — это всегда платная версия?

У вас в статье про self-hosted очень мало сказано
Мы еще не до конца проработали ценовую модель, ближе к релизу всё поймем и расскажем.
Как вариант — предоставлять self-hosted бесплатно для opensource проектов.
Я не против готового инструмента, где можно делать все. Просто, учитывая опыт других подобных решений, есть ощущение, что «ну его...». У вас отличные IDE и TeamCity. Atlassian имеет отличные Jira, Bitbucket и Confluence. Большие команды, где, действительно, нужно начинать серьезно экономить на стыке инструментов, как раз не готовы к таким универсальным вещам. Им нужна Jira, TeamCity, Idea, Bitbucket (утрировано). Т.е., лучшее от каждого. Как мне кажется, даже HipChat не особенно взлетел, хотя там интеграция…

Время покажет…
Время всё рассудит, но, имхо, при следующей итерации покупки/обновления лицензий многие подумают — «а нафига нам этот зоопарк, давайте попробуем Space, соседская тима пищит уже с год как ...».
Если бы все было так просто. Проблема не в этом, а в миграции на новые инструменты.
Я не говорил, что это будет просто. Я говорил, что такие мысли возникнут при обновлении/покупке новых лицензий.

PS. Миграции тоже бывают разные, маленькой команде достаточно сдампить и импортировать нужное. Для больших — заморозка в RO существующих инструментов и перекатывание на новое место. Всё очень сильно зависит от.

Про отличный битбакет который каждый день висит с желтой плашкой "мы испытываем проблемы, но скоро всё будет ок" я бы послушал :)

Так это облачный. А есть он-премис
И, да, гитлаб последний месяц шатает тоже прилично
У тебя демо у заказчика и тут платный (!) Гитлаб ломается, потому что в Гугле авария.

Меня тревожит немного другое. Как бы вся эта политизированная движуха вокруг России не сыграла дурную шутку (нечестная конкуренция/протекционизм) с продуктами Jetbrains. Тьфу-тьфу-тьфу.

PS. Намекаю на случай с Gitlab.
Да, я об этом же. В статье можно изменить Kaspersky на Jetbrains и приехали, будут продвигать свой Eclipse Che/whatever с обвесом и интеграциями.

Вообще говоря «свой» VisualStudio и VisualStudio Code уже далеко по сравнению с IntelliJ продвинулся, судя по статистике StackOverflow.

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

Плюс различных сервисов в том, что ты можешь выбрать нужные для себя, в зависимости от потребностей.
В единых сервисах обычно или чего-то не хватает. Или наоборот, слишком монструозен, чтобы использовать весь функционал правильно.
Мы очень постараемся сделать так, чтобы всего хватило, было удобно и сбалансированно, мы тоже разработчики и потребности у нас похожие. А пока просто попробуйте продукт и напишите нам фидбек :)

Поэтому переиспользовали название питерского офиса для названия продукта?


Или я ошибаюсь с названием офиса в Питере? У меня вон даже футболка: Find your place in Space ;)

Это просто совпадение, нельзя же было отказываться от хорошего названия для продукта просто потому что так уже назвали офис :)

Впрочем, мы планируем сделать базу знаний, так что ответ "да", если у вас нет каких-то специфичных сценариев.

Божественно! Я уже 10 лет жду от JB нормального решения для управления знаниями, кроме вас некому :)

Потому что всевозможные wiki — это невероятное убожество, а кроме Confluence, которая тащит за собой отстойную Jira, на рынке до сих пор ничего нет.

А отдельного такого продута не планируется, все будет засунуто в Space?
Отдельного пока не планируется, но если Вы уже используете YouTrack то следите за новостями :) Там тоже скоро появится база знаний с разграничением прав доступа, визуальным и markdown редактором и пр.
Подробнее можно почитать тут:
blog.jetbrains.com/youtrack/2019/07/whats-next-youtrack-roadmap-2019-q3-q4
Для меня прямо тайна — в чём killer-feature of Confluence?

От обычной wiki-системы отличается тем, что
— есть группы
— у каждой страницы есть комментарии

И тем не менее уже в нескольких компаниях её ставят и платят за неё деньги. За что именно ценят Confluence?
За что именно ценят Confluence?

За удобство.
Даже просто такая мелочь: Картинку (например скрин с экрана) кинул в буфер и вставил в текст. Оно само там сохранилось и вставилось.
Макросы со вставкой кода с подсветкой синтаксиса.
Поиск.
Просто удобный интерфейс. Удобный, интуитивно понятный редактор (не нужно там теги какие то изучать как в обычной WIKI), люди начинают работать практически без обучения.
Страницы и разделы легко перетаскиваются в другое место в иерархии (не всегда стразу структура ясна).
Да и цена 10$ за 10 логинов (потом резко растет) навсегда (при установке на свой сервер и без обновлений через год) как то не кусается. При этом работать может множество людей одновременно, заходя под одним логином.
У нас дали логин для операторов горячей линии и выделили им пространство, они там себе хелпы сами создают с картинками. Очень довольны.
Спасибо, понятно.

Кстати, да — редактор у них действительно неплохой.

Вы только про «один логин для операторов» не светитесь, потому что это вроде как нарушение лицензии
Вы только про «один логин для операторов» не светитесь, потому что это вроде как нарушение лицензии

С чего вдруг?
В системе ограничение на количество логинов. Его никто не нарушает.
Вы можете в любой системе (к примеру е-майл) сообщить любому количеству людей свой логин и пароль, на свой страх и риск. И они будут заходить и ломать там что либо, на ваш страх и риск.
Разделение на логины оно же для контроля сделано. Если вам контроль не нужен, ваша головная боль.
А большее число логинов лицензия не позволит. Они грамотно сделали. Поработав в конфлюенсе уже не хочется чего то там изучать другое и тратить на это время. Я уже в 3-й организации убедил внедрить эту штуку.
Где то остановились на 10 лицензиях, а где то закупили более, где критичные данные.
Существует довольно много коммерческих продуктов, которые вообще не требуют каких-то ключей и не имеют технически ограничений, но это же не значит что они теперь бесплатны. В длинном тексте лицензии обычно всё это расписано, что за такое поведение есть ответственность.
поиск в конфлюенсе — ультимативно худший поиск среди всех продуктов что я когда-либо пользовался.

Как для базы знаний — это достаточный аргумент чтобы бороться против использования конфлюенса. Даже чаты (слак или телега) лучше ищут.
По словам отлично ищет.
Метки можно ставить. Быть может есть внешние приблуды для улучшения поиска, нам везде хватало (и хватает) того поиска, что есть, поэтому я не интересовался. Как бы никто не «борется против» конфлюенсе.
Впрочем, я не продаю конфлюенсе, мне индифферентно, кто и что использует в других местах, каждый выбирает для себя, лишь бы нравилось.
А мне нравится, что он ищет даже слова во вложенных файлах — word, excel, и кажется pdf (не уверен, но думаю так). Очень много раз помогало находить нужную информацию в огромной куче информации.
UFO landed and left these words here
Как уже было сказано выше, у нас будет база знаний и у нас уже есть клевый WYSIWYG редактор, который используется в блогах Space. Можете зайти и попробовать, потом расскажете что понравилось/не понравилось в сравнении с редактором из конфлюенса.
Интеграция с Jira вам не понадобится, т.к. у нас есть Issues прямо в продукте.
Ясно, понятно, так и запишем «глючное гов**»(
Не видел еще ни одно крупное приложение на Electron, которое бы не жрало оперативу и проц.
У вас же есть Kotlin/Native, почему его не использовали?
Казалось бы, есть веб версия, но она у вас написана на kotlin-react, т.е на Kotlin to JavaScript, и я сомневаюсь, что на таком огромном проекте это производительное решение.
А как же vscode? На линуксе 400мб памяти занимает, при этом открыт воркспейс с десятком средних проектов, работает быстро.
Не видел еще ни одно крупное приложение на Electron, которое бы не жрало оперативу и проц.

Известное мне исключение — Discord под Windows, т.к. конфиг Electron неизкоробочный и активно фиксят все утечки памяти.

Десктопный Slack, например, — тоже Electron.
И работает нормально.

На компьютере с озу > 4гб. А иначе — нет. Хотя, безусловно, было еще хуже — недавно что-то поправили.

Вот просто взял и посмотрел. Сию минуту на моей машине Slack жрёт больше всего RAM из всех запущенных приложений. Среди которых, на минуточку, есть такие как PyCharm и VirtualBox, например. Это успех, да.

Kotlin Native есть, но под него ещё нет ни одного UI-фреймворка, тем более кроссплатформенного.

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

Как раз ищем куда бы перейти с текущей CRM и как раз так что б все в одном месте.

Выглядит все очень круто и перспективно.

Ждем инвайт готовы тестить и интегрировать себе в работу, у нас команда порядка 30 человек на текущий момент перекрываем все с помощью Asana + Slack + GitLab + Google Calendar. Но судя по всему под наши задачи как раз было бы идеально ибо в планах добавить еще доку + блог + тайм трекинг в итоге получиться зоопарк приложений что очень не комфортно
Стоп, вы считаете время своих сотрудников, т.е. условно каждая минута на счету, но готовы перейти на новый продукт, первую сыроватую версию, замедлив в любом случае разработку, потратив ресурсы 30 человек на обучение всей команды? Не вижу логики. По мне так лучше бы кто-то один потестил, и лишь потом решил — переходить ли всем остальным через речку.
Ну это так, не камень в JT кидаю, а вообще с любым нововведением надо быть аккуратным, если считаешь деньги.

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

Так, читаю
хостинг Git-репозиториев, код-ревью, автоматизацию (CI/CD) на основе Kotlin-скриптов, репозитории пакетов, инструменты планирования, трекер задач.
Звучит неплохо. Читаю дальше
профили команд и сотрудников, чаты, блоги, календари, возможность планировать встречи

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

<:o)
Потому что в концепте с интеграциями неизбежно возникают различные проблемы интеграций, несовместимость версий и т.п. Подход с единой системой позволяет значить улучшить качество продукта и опыт его использования.
UFO landed and left these words here
Выглядит монструозненько.

Можно ли как-то отключать ненужные компоненты?

А вот сделали бы конструктор — каждая команда нашла бы что-то для себя. А так будут взвешивать ± перед тем как полностью переходить и не факт что в вашу пользу. Как по мне, то это сразу потеря клиентов.
Запаковывать всё в одну систему нужно уже потом, когда есть активные пользователи и им можно предложить внутренний аналог удобнее чем внешний, который они уже используют, но находясь в вашей системе. И не всё сразу, разумеется.

Так а в чем проблема не пользоваться тем, что в данный момент не нужно?

Отсутствие интеграции с тем, что нужно? Хорошо, если она будет, конечно.

В том, что загружаете всё, тратятся ресурсы, особенно учитывая, что у них обёртка для десктопа на электроне. Вы не используете то что не нужно, а оно у вас в фоновых процессах всё равно висит и грузится при запуске.
Сделали бы конструктор — получили бы аналог существующих продуктов на рынке. А так получился комбайн, где каждый компонент знает про другой: код ревью тул знает об отпусках, чат знает о комментариях в блоге, гит знает о команде коммитера, а поиск ищет через это все. Не нужно бегать из одной системы в другую, чтобы отвечать на простые вопросы, которые возникают по многу раз в день.

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


бегать из одной системы в другую

Это вполне привычно и не так сложно при хорошей интеграции. Например G-suite с календарём — а теперь взять и мигрировать на какой-то новый календарь, который непонятно как (никак скорее всего) интегрируется с тем же G-suite. Или слэк с несколькими аккаунтами для разных проектов, где пользователи легко перетекают из одной в другую тесно интегрируясь с другими компаниями — а теперь предлагается какой-то свой чат, куда нужно будет или приглашать другие команды каким-то образом, или просто пользоваться несколькими чатами вместо одного (у нас 10 стандартов — нужно сделать один универсальный. Теперь у нас 11 стандартов).

Про текущий стек вполне понятно и обоснованно. Именно поэтому Space имеет возможность интеграции. Например, G Suite в JetBrains используется очень активно, поэтому все митинги дублируются и там, и там. Но, кажется, что конструктор здесь не причем. Конструкторы уже есть на рынке, и то, чего им обычно недостает, так это хорошей интеграции друг с другом. Не очень очевидно, зачем делать еще один.
По ценовой политике — нет аналога Community Edition как в Gitlab-e, нет аналога 10 юзеров за $10 навсегда от Atlassian-а. Фокус на «большие компании несите нам свои большие деньги». Ну такое…
Ну, это пока. Когда будет готова версия on-premise, тогда можно будет сравнивать с аналогами от конкурентов.
Там под другим комментарием написали, что не планируют бесплатную on-premise.
И там же написано, что ценовая модель для on-premise пока не проработана до конца. Когда ее объявят, тогда и можно будет с уверенностью о чем-то говорить.

Очевидно же — модель ценовой политики должна быть не хуже, не дороже, чем у конкурентов (гитлаб, атлассиан и пр). А так же — бесплатная лицензия для опенсурса. И рассмотреть какие-то точечные предложения вроде не "подписка по кол-во пользователей", а "вечная лицензия", но "без апгрейдов"

Предложение.
Сделайте программирование CI/DI etc на многих языках.
Что-бы те кто в сновном программируют на языке Х — на нём же и делали CI/DI.
Вроде бы выглядит не сложно но по факту вместо единой системы появилась ещё одна для любителей котлина.

кажется, теперь ясно, почему вот уже несколько лет вы не чините авторизацию к продуктам Atlassian: https://youtrack.jetbrains.com/issue/IDEA-149504
Казалось бы, раньше можно было сказать, что зачем, если есть простая авторизация. НО несколько месяцев её уже нет совсем, а эту так и не прикручиваете. Как итог — вся интеграция в IDEA накрыта тазиком

Авторизацию починила давно, единственное отличие в том, что в UI не исправили Password на API Token (можно по комментариям отследить).


EDIT: хотя видимо всё ещё не работает для JIRA Server

хотя видимо всё ещё не работает для JIRA Server

Проверил — в последней версии IDEA работает. Но с небольшой особенностью — сперва показывается форма с логин/пароль, а потом она меняется на логин/токен и можно момент смены поля пароля на поле токена прозевать. Не критично, так как в целом уже пашет.
Собственно, именно этот момент смены поля я и прозевал… :(

Нет, почему? Space-аналоги вряд ли когда-нибудь догонять эти продукты по функциональности, особенно учитывая, что они тоже не стоят на месте и активно развиваются.
тогда как? для полного функционала тим-сити и ютрек, но в спейсе — дубликат данных? или интеграция?
Нет, разные целевые аудитории. Как показал опыт GitHub/GitLab, не всем нужен полновесный трекер с воркфлоу и репортами. Хочется всего и сразу — Space. Нужны мощные инструменты — TC/YT/US.
Ребята, ну это не серьёзно. Нужен ещё заказ пиццы, такси, чтоб варило кофе и дешёвые авиабилеты в отпуск искало.
Space будет расширяем, поэтому если вам лично или вашей компании будет нужна интеграция с сервисом заказа такси — ее можно будет сделать.
Хм… отличная идея для пет-проекта: Автоматический заказ пиццы для Ретроспективы например…
а как прелагается переходить на спейс для разрабатываемых проектов?
К примеру, у нас щас гит — в битбакете, таски — в жире, календарь — в гугле, CI — от Circle CI.
Всё уже настроено и работает. А, слак забыл. каналы, уведомления о билдах и даже общение с заказчиками (у них свой слек, и есть общие каналы)

как это все перетащить в спейс? Будет какой-то импортер этого всего с историей или как?
Будут ли плюсы от спейса стоить всех тех телодвижений по переносу процессов существующего проекта?
А это заменит связку gitlab community как хостинг гита + TeamCity Enterprise на 3 агента как CI и багтрекер вообще отдельно и всё это добро на 200 пользователей?
Причём вопрос не только в функциональности, но и пожалуй в цене.
Для хостинга гит репозиториев оно будет кушать ресурсов больше чем гитлаб или меньше?
Сможет ли оно нормально работать на изолированной от интернета машине? (ну понятно что без всяких зеркаилрований репозиториев из коробки.)
Можно ли в нём отключить все вот эти чатики и так далее?
С одной стороны хочется верить что уж у JetBrains то точно получится нормально сделать всё в одном. С другой стороны пока ни один из таких многоликих проектов не выполняет хорошо всё что умеет, а из за этой многоликости страдает основная функциональность :(
А зачем же вам тимсити на 3 агента как CI, если у вас gitlab как хостинг гита? Прикрутили бы уже и гитлабовский CI — оно и гармоничнее, и более целостно.
Тимсити жила ещё до гитлаба. Переход на гитлаб CI не даёт очевидных преимуществ — а объём работ по миграции огромный.
Ну, если они продают «CI credits» в тарифных планах, то, наверное, будет.
Отличная задумка. Выбор должен быть, и конкуренция это здорово. А как на счет тёмной темы? Есть ли из коробки или планируете ее реализовать? Как дела с расширениями, можно ли будет писать свои расширения, аналогично Azure Devops Services?
Темную тему мы добавим, пока можно сделать только темный side bar. Писать свои расширения можно будет, но плагины будут доступны только для self-hosted версии.
Мне очень нравится и идея, и с виду реализация самого продукта.
Вопрос, будет ли широкое тестирование self-hosted версии? Немного страшновато что от одного продукта может полностью зависеть работоспобность компании.
И как будет self-hosted реализован? Как множественные компоненты работающие отдельно или монолитный сервис? Или наподобие gitlab можно будет выбирать какие компоненты выносить на отдельные сервера?
Вопрос, будет ли широкое тестирование self-hosted версии? Немного страшновато что от одного продукта может полностью зависеть работоспобность компании.

Да, будет, конечно, но пока сроков по self-hosted точных нет.

И как будет self-hosted реализован?

Это будет единая инсталляция, которая поставляется как единое решение. После установки все компоненты будут доступны, но их не обязательно все ипользовать одновременно. Можно, например, начать с команд, потом добавить чаты, потом постепенно заводить проекты.
Хм, немного другое имел ввиду под монолитностью.
К примеру, у гитлаба при большой нагрузке на redis — его можно вынести из самой инсталяции на другой сервер. Перегрузка sidekiq — и его можно вынести. И так далее почти на все внутренние компоненты.
Будет ли для Space похожая структура?
UFO landed and left these words here
Как планируется сделать вики — как отдельный вики-движок, или Git репу (как в гитлабе)?
Планируются ли какие-то инструменты для того, чтобы интегрироваться в вики (аддоны в редактор, аддоны во вьюхи, хуки на редактирование)?
Сделайте пожалуйста оплату в рублях через выставление счета. В госкомпаниях это самый простой способ воспользоваться вашими продуктами
Большие закупки так и делаем, но это долго и муторно (вот в этом и проблема)
небольшие (до 100 тысяч) можно оплатить через счет
Если получится сьехать с неповоротливой жиры на данный продукт — будет просто великолепно. А как быстро принимают инвайты на потестить?
Скажите, а как быстро инвайты раздаются?
А то подписался на EAP 3 дня назад, и тишина… а хотелось бы потестить
Не волнуйтесь, мы всех впустим, мы получили очень много запросов. Обрабатываем их последовательно.

Весь мир уходит от монолита в микросервисы.
Jetbrains — пилим монолитный инструмент.


Возможно этот фарш ещё можно провернуть назад. Мне очень нравилась идея Hub, но она всегда была несколько не полноценной. Там не было именно многих интеграций, которые вы тут запилили, типа профиля пользователя с его отпусками, мессенджерами, базами знаний и тд. Уж если разные версии это такая проблема, то прибейте их гвоздями, типа с чатом версии 2011.1.1 может работать только CI/CD той же версии и тд.


Плюсы когда это разные продукты очевидны. Вот поставил простенькую Wiki и для десятка статей всё работает. Растём? Вот на этот сервак я поставлю CF. Надо больше памяти ему закинуть? Ну на. Надо обновить? Ок, вот на соседнем подниму, потестирую и переключу. Начал тупить чатик? Поменяю его, не обновляя остальное.


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


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


YT, TC, US всё равно не заменяет эта штука и не догонит уже. А вот свой хостинг репозиториев, чаты, базы знаний, внутренние порталы сотрудников и всякие другие инструменты гармонично интегрируемые в Hub вот чего не хватает чтобы плавно переходить на продукты JB.

Весь мир уходит от монолита в микросервисы.

Вот гитлаб прямо иллюстрирует этот принцип — неудивительно, что они пилят комбайн /sarcasm mode/. Микросервисы же это про другое. Продукт может быть единым, но состоять из модулей.

Вы годами не могли сделать мануальный approve в teamcity, наивную интеграцию со Slack, зато тут все прямо сверкает.
Значит ли это что teamcity вообще больше не будет развиваться?
Все говорят «Много всего — это круто». Но для меня это не так.
Мне нужна ограниченная часть функционала. Остальной же функционал будет просто мешать. Это вечная проблема «Делаем все для массового потребления».

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


Да мы можем с помощью чеклистов видеть прогресс проекта но все равно эта информация не дает нам понять когда же проект будет сдан


А так же не видно загрузку команды. Итого получается что для работы над проектом все удобно и в одном месте но для контроля все ли ок успеваем ли во время кто загружен а кто гуляет прийдется использовать еще какой то инструмент?


Есть ли какие то планы по этой части?
Или что рекомендуете использовать в связке для решения данного вопроса?

Да, мы планируем добавить трекинг по времени и возможность создавать дедлайны.

Это очень нужная задача. Без этого управление командой никак не работает.
Пожалуйста, дайте ей приоритет.

А?! Я шестого числа еще утром зарегался… до сих пор ничего нет. Вы как без очереди прошли? =)
Еще есть пару вопросов:
1. Где можно следить за изменениями что поменялось и добавилось нового в Space?
2. А как создать чат под проект? Сейчас получается что чат автоматом создается по задачам, но логично так же создавать чат под проект что б можно было обсуждать его глобально, в целом не вижу проблем создать его руками но логично было бы иметь возможность автоматической привязки, что б состав участников что в проекте, что в чате, синхронизировался а так же логи по всем изменениям падали в общий чат.
То есть мы получим канал в котором видны любые действия по проекту
1. В будущем можно будет читать про обновления прямо в Space. А пока можно следить за новостями продукта в твиттере и блоге.
2. Чат под проект можно создать вручную и добавить туда команду проекта. Спасибо за фидбэк, я создала реквест, обсудим с командой.
И подскажите куда слать багрепорты?
— К примеру нет возможности удалить проект
Сегодня начали использовать Space. В общем всё нравится. Не нашёл возможности экспорта из pivotal — плохо искал или нет такого? А если нет, то будет-ли? А если будет, то когда?
Пока экспорта из других продуктов нет, но в будущем будет. Спасибо за фидбэк!
В роадмапе есть такой пункт или это только предположение без каких либо сроков? Для нас это важно.
Экспорт из других продуктов есть в нашем роадмапе и скорее всего появится к Space 1.0, но по срокам пока ничего не можем сказать.
Я как раз имела ввиду, что сроки по релизу Space 1.0 пока не можем озвучить.
Я правильно понимаю, что можно будет без проблем мигрировать в Space из Youtrack, например?

Или если не мигрировать, то будет ли интеграция между продуктами?
Можно будет частично мигрировать в Space из YouTrack (например, миграция покроет перенос задач), интеграция также будет сделана в базовом виде (планируется интеграция с профилями, календарями, отпусками из Space, интеграция с Space VCS, и тд.)

P.S. Извиняюсь, что только сейчас ответила, пропустила нотификацию и не видела коммент =(
интересно, используется Exposed, а как насчет миграций, знаю что в Exposed инструмента для миграций нету
Какой инструмент используете?
moscas nkatson
Мы пока не используем специального инструмента для управления версиями схемы базы данных. Схема определена непосредственно в коде бэкенда и изменяется так, чтобы старая версия сервера могла работать с новой схемой. При старте сервера схема базы приводится в соответствие с определением в коде средствами Exposed — github.com/JetBrains/Exposed/blob/master/exposed-core/src/main/kotlin/org/jetbrains/exposed/sql/SchemaUtils.kt#L229.

nkatson
Не в тему вопрос, но мне важный.
А будет ли когда-нибудь продукт для Ops-ов?
Чтобы:


  • Поддерживалась Ballerina
  • Был удобный UI для helm, запоминающий namespaces, с которым работаем
  • Был UI с сессиями SSH прямо оттуда (и управлением ключами, подгруженными в ssh-agent, чтобы люди не гадали, сколько ключей загрузили и почему не могут при наличии 11-го ключа зайти)
  • Получение алертов от alertmanager.
  • Панели liveness probe/health probe для разных сервисов в одном месте (как сейчас сделано с базами данных)
  • Скаффолды для Jenkinsfile, .circleci/config.yml (для Jenkinsfile еще и подсветка синтаксиса)
  • Панель с состоянием Terraform деплоев
  • Управление игнишеннами для CoreOS
  • Управление пакетами Galaxy (Ansible) и паролями для Vault
  • etc
  1. Я подозреваю, что ваш комментарий был проигнорирован потому, что вы в одном комментарии смешали несколько тем. Как минимум тему востребованности продукта Space и тему того, что нужен другой продукт. Если вы не атомарно доносите вещи, то они воспринимаются людьми как неконструктивные и игнорируются.
    Еще сильнее они выбивают землю из под ног конструктива, если у них осуждающий формат, а не предлагающий.


  2. Возможно, это не тот способ обратной связи и не та тема, которые они обрабатывают. Когда я писал им в саппорт по вопросу тимсити, мне ответили быстро. Посмотрим.


когда я писал комментрарий — вторая тема и была конструктивной, как контр мера к первой деструктивной теме
Пока планов на отдельную IDE нет, но мы работаем над улучшениями в области разработки, связанными с облачными нативными приложениями. Большинство вышеперечисленных фич скорее всего будут покрыты в ходе работы.
А можно поинтерисоваться почему?
1) ДевОпсов больше чем ДБА
2) Инфраструктура имеет принципиально другую структуру, чем проекты. Проект — вот он в папочке. Если он в другой папочке — это другой проект.
Инфсраструктура всегда одна. В какой бы ты не был папке, иде или компьютере.
3) Накручивание инфраструктуры вокруг проекта выливается в кучу неприятных особенностей. Например харкод большинства вещей. Которые потом очень долго выпиливаются из ИДЕИ и подаются как большие фичи.
4) Сначала вещи связаны между собой в инфраструктуре (бд, вебсервер, конфиги и прочее) и только потом с проектом. Сейчас же все ИДЕ все привязывают к проекту. И суть одна настройка (например чей-то порт) находится в нескольких местах

И банальные вещи приводят к длительному поиску хардкода. Например, если мне надо запустить один и тот-же проект 2 раза — я замучаюсь перенаходить все настроки портов, аддресов, докера и прочего.
Конечно, IDE для Ops — это отличный продукт, который был б полезен многим специалистам. Но на данный момент мы всё же планируем добавлять функциональность, которая покрывает разработку приложений для облачных сред, в текущие IDE.
Все улучшения будут доступны в IntelliJ IDE (некоторые фичи войдут и в другие IDE от JetBrains).
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

1 March 2000

Location

Россия

Employees

1,001–5,000 employees

Registered

2 December 2008

Habr blog