Comments 229
Я правильно понимаю, что это аналог Team Foundation Server от Microsoft. Вроде бы там есть почти всё то же самое?
Почему вы сделали новый CI/CD, а не интеграцию c TeamCity?
*анекдот о том, что очень нужны были деньги*
… но со вренем выяснится, что ту же Jira всё равно не догнать ни по функционалу, ни по масштабам интеграции со всех сторон, так что вариант "всё своё, а таски — в Jira" уже не будет казаться таким дурным… а значит нужна интеграция с Jira, а там и… ой, где это мы?
Все не так плохо и ужасно. Даже если Jira навязана сверху, то это просто приводит к существованию 2+ систем ведения отчетности. Ну, вы же знаете. Команда сидит в каком-нибудь трелло, а в жира отчестность чисто для галочки, поэтому жирой в принципе невозможно эффективно пользоваться.
Я пишу разные проекты и иногда хочу открывать репозитории для внешнего участия. На гитхабе я просто делаю репу публичной.
Здесь получается, всем участникам придется зарегистрироваться в Space и возможно даже вступить в мою "команду"?
Коммитить можно и туда, и сюда одновременно.
Что-то? Расшифруйте? Потому что очевидно, что если будет бардак и разрабы будут коммитить в оба репозитория, то вы потом замучаетесь конфликты лечить (ибо синхронизация никогда не бывает мгновенной, а только лишь eventually). Итого — мы приходим к тому, что какая-то репо будет read-only, а вторая — master, либо как-то строить конвенции по веткам.
За всех вы, конечно, перегнули палку, слегка.
Количество пользователей Atlassian(а это не только JIRA) и TFS — очень велико.
Да знаю, знаю — «им никто не пользуется».
Получится комбайн. Девиз любого комбайна — "все, сразу, но нифига толком".
Зачем?
Так а как попробовать? Или зачем ваш обзор?
Отправьте заявку, Вам ее одобрят очень
Видимо, только если вы большая компания.
Наша компания подписана на продукты JetBrains, периодически репортим баги, как минимум один был признан критическим (в Resharper). Пользуемся TeamCity.
Однако инвайта пока нет…
Jenkins не хостит внутри себя гит.
Мне одному кажется что это направление уже доказало свою бесперспективность?
Бизнес хочет единое решение, с возможностью заплатить в одно место и больше не иметь головной боли.
Бизнес хочет единое решение, с возможностью заплатить в одно место и больше не иметь головной боли.
Минус таких решений в том, что они более скудны в функциональности, чем отдельные проекты. А попытка затащить весь функционал чаще всего приводит к появлению ещё одного неповоротливого монстра
Далеко не каждый бизнес хочет получить вендор-лок, если что.
И поэтому очень часто разные части процессов делаются тулами от разных производителей.
Теперь остается узнать насколько Space будет удобна в использовании (по коммиту протестировалось/отдеплоилось/откатилось/оповестило при фейле/выкатилось по записи в каледаре) и т.д.).
я поэтому и думал про возможность внедрить phabricator в отдельно взятой организации — как решению полного цикла.
Вместо выработки стандартов и клиентов
Дичайшая жиза.
С теплотой вспоминаю свою систему в 2012 году — ВКшечка, аська, фейсбук в айчате, интегрируются нативно в ОС, разве что скайп для периодических переговоров, ну и фидо кроме терминала никак. Сайты все подвязывались в Reeder. Календари расшаренные и прочее офисное барахло подвязывалось в системный органайзер. Браузер по итогу был практически не нужен.
А теперь каждому подавай или вкладку браузера, или новую прилагу, которая зачастую тоже браузер. Интегрированные в ОС тулзы ни к чему не подходят, если не хочешь сидеть исключительно в разжиревшей кастрированной экосистеме вендора. Ибо чем дольше ты сидишь в "продукте", тем больше денег приносишь, а если ты тупо к нему по XMPP цепанулся и не любуешься на продукты жизнедеятельности дизайнеров — как же писать твои повадки для продажи и втюхивать рекламу взамен?
CS развивается семимильными шагами, инструментов очень много. Если в условном начале 2000-х их было совсем мало, то теперь проблема выбора продукта встала в полный рост. Какие стандарты могут появляться в столь динамичной среде? Насколько они будут актуальны, кто будет владелец и в какой стране они будут приниматься, какие гарантий развития и взаимодействия с сообществом?
То есть, если договориться по поводу протоколов трансграничного сетевого взаимодействия и геометрии шлюзов МКС мы еще как-то можем, то принимать какие-то стандарты в крайне динамичной среде со множеством участников — затея абсолютно нежизнеспособная (собственно, мы это наблюдаем сейчас).
en.wikipedia.org/wiki/Language_Server_Protocol как отправная точка
PS я ожидал ИДЕ для управления серверами, доступами, облаками и прочим девопсом, навороченная консоль. Как датагрип для ДБА только для девопсов.
Я начинаю понимать. Вы спроецировали свои желания иметь универсальный инструмент для разных вендоров, чтобы всё это было удобно/бесшовно.
Не буду повторяться — это не отвечает реальности — перечитайте мой комментарий выше.
PS. Сам я буду использовать того вендора (платить ему деньги), который даст мне наиболее удобный инструмент. Ждать, когда появится «универсальный универсал» с поддержкой всех и вся — не намерен.
вы можете придти на проект и написать свои инструменты для разработчика под свою любимую IDE. И поддерживать их (инструменты) потом дальше.
Но гораздо выгоднее заточиться под конкретную, выбранную командой, IDE и не распыляться на зоопарк остальных.
Аналогично и с выбором ОС в компании — зоопарк надо поддерживать кому-то. Либо вы делаете сами, без ущерба для основной рабочей деятельности, либо аргументируете работодателю, почему он должен оплачивать эти часы админам, либо платите админам сами.
Интересно будет посмотреть.
Время покажет…
PS. Миграции тоже бывают разные, маленькой команде достаточно сдампить и импортировать нужное. Для больших — заморозка в RO существующих инструментов и перекатывание на новое место. Всё очень сильно зависит от.
Про отличный битбакет который каждый день висит с желтой плашкой "мы испытываем проблемы, но скоро всё будет ок" я бы послушал :)
PS. Намекаю на случай с Gitlab.
На зря же JetBrains давно маскируется под чешскую контору. С другой стороны определённые риски тоже не стоит недооценивать.
Как человек, только входящий в айти и встречающийся лицом к лицу с просто невменяемым количеством сервисов, которые нужны для работы, потому что общаться туда, коммитить сюда, официальная рассылка там, митинги здесь — могу только радоваться попыткам этот зоопарк собрать в одном красивом месте. Вряд ли удастся в ближайшее время пощупать руками, но сама концепция — на пять с плюсом.
В единых сервисах обычно или чего-то не хватает. Или наоборот, слишком монструозен, чтобы использовать весь функционал правильно.
Впрочем, мы планируем сделать базу знаний, так что ответ "да", если у вас нет каких-то специфичных сценариев.
Потому что всевозможные wiki — это невероятное убожество, а кроме Confluence, которая тащит за собой отстойную Jira, на рынке до сих пор ничего нет.
А отдельного такого продута не планируется, все будет засунуто в Space?
Подробнее можно почитать тут:
blog.jetbrains.com/youtrack/2019/07/whats-next-youtrack-roadmap-2019-q3-q4
Кроме Space-а фича Базы знаний будет доступна в YouTrack, следите за новостями.
blog.jetbrains.com/youtrack/2019/07/whats-next-youtrack-roadmap-2019-q3-q4
От обычной wiki-системы отличается тем, что
— есть группы
— у каждой страницы есть комментарии
И тем не менее уже в нескольких компаниях её ставят и платят за неё деньги. За что именно ценят Confluence?
Интеграция с Jira вам не понадобится, т.к. у нас есть Issues прямо в продукте.
Десктопный клиент как сделан? Небось просто обёртка над Chromium?
Не видел еще ни одно крупное приложение на Electron, которое бы не жрало оперативу и проц.
У вас же есть Kotlin/Native, почему его не использовали?
Казалось бы, есть веб версия, но она у вас написана на kotlin-react, т.е на Kotlin to JavaScript, и я сомневаюсь, что на таком огромном проекте это производительное решение.
Не видел еще ни одно крупное приложение на Electron, которое бы не жрало оперативу и проц.
Известное мне исключение — Discord под Windows, т.к. конфиг Electron неизкоробочный и активно фиксят все утечки памяти.
Десктопный Slack, например, — тоже Electron.
И работает нормально.
На компьютере с озу > 4гб. А иначе — нет. Хотя, безусловно, было еще хуже — недавно что-то поправили.
Kotlin Native есть, но под него ещё нет ни одного UI-фреймворка, тем более кроссплатформенного.
О, Omea ожила.
Не увидел нигде в описании, а есть ли или можнт быть планируется тайм трекинг в задачах?
Выглядит все очень круто и перспективно.
Ждем инвайт готовы тестить и интегрировать себе в работу, у нас команда порядка 30 человек на текущий момент перекрываем все с помощью Asana + Slack + GitLab + Google Calendar. Но судя по всему под наши задачи как раз было бы идеально ибо в планах добавить еще доку + блог + тайм трекинг в итоге получиться зоопарк приложений что очень не комфортно
Ну это так, не камень в JT кидаю, а вообще с любым нововведением надо быть аккуратным, если считаешь деньги.
хостинг Git-репозиториев, код-ревью, автоматизацию (CI/CD) на основе Kotlin-скриптов, репозитории пакетов, инструменты планирования, трекер задач.Звучит неплохо. Читаю дальше
профили команд и сотрудников, чаты, блоги, календари, возможность планировать встречи
Ну вот, здесь вы меня потеряли… Почему нельзя делать простые инструменты, которые хорошо решают каждый свою задачу и если нужно интегрируются друг с другом.
Оно главнее всех,
Оно соберет всех вместе
И заключит во тьме.
(с) Не мой
<:o)
Можно ли как-то отключать ненужные компоненты?
А вот сделали бы конструктор — каждая команда нашла бы что-то для себя. А так будут взвешивать ± перед тем как полностью переходить и не факт что в вашу пользу. Как по мне, то это сразу потеря клиентов.
Запаковывать всё в одну систему нужно уже потом, когда есть активные пользователи и им можно предложить внутренний аналог удобнее чем внешний, который они уже используют, но находясь в вашей системе. И не всё сразу, разумеется.
Потому что переход на это сделать крайне сложно. Взять проект который уже живёт два года — да никто не будет там так глобально ничего менять. А заменить конкретно взятый инструмент другим — возможно.
Одна экосистема хорошо. Но заменить текущий стек совершенно новым — почти нереально для больших команд или очень дорого для бизнеса. Потому я и говорю про плавный переход. Время на адаптацию, чтоли.
бегать из одной системы в другую
Это вполне привычно и не так сложно при хорошей интеграции. Например G-suite с календарём — а теперь взять и мигрировать на какой-то новый календарь, который непонятно как (никак скорее всего) интегрируется с тем же G-suite. Или слэк с несколькими аккаунтами для разных проектов, где пользователи легко перетекают из одной в другую тесно интегрируясь с другими компаниями — а теперь предлагается какой-то свой чат, куда нужно будет или приглашать другие команды каким-то образом, или просто пользоваться несколькими чатами вместо одного (у нас 10 стандартов — нужно сделать один универсальный. Теперь у нас 11 стандартов).
Сделайте программирование CI/DI etc на многих языках.
Что-бы те кто в сновном программируют на языке Х — на нём же и делали CI/DI.
Вроде бы выглядит не сложно но по факту вместо единой системы появилась ещё одна для любителей котлина.
кажется, теперь ясно, почему вот уже несколько лет вы не чините авторизацию к продуктам Atlassian: https://youtrack.jetbrains.com/issue/IDEA-149504
Казалось бы, раньше можно было сказать, что зачем, если есть простая авторизация. НО несколько месяцев её уже нет совсем, а эту так и не прикручиваете. Как итог — вся интеграция в IDEA накрыта тазиком
Авторизацию починила давно, единственное отличие в том, что в UI не исправили Password на API Token (можно по комментариям отследить).
EDIT: хотя видимо всё ещё не работает для JIRA Server
хотя видимо всё ещё не работает для JIRA Server
Проверил — в последней версии IDEA работает. Но с небольшой особенностью — сперва показывается форма с логин/пароль, а потом она меняется на логин/токен и можно момент смены поля пароля на поле токена прозевать. Не критично, так как в целом уже пашет.
Собственно, именно этот момент смены поля я и прозевал… :(
К примеру, у нас щас гит — в битбакете, таски — в жире, календарь — в гугле, CI — от Circle CI.
Всё уже настроено и работает. А, слак забыл. каналы, уведомления о билдах и даже общение с заказчиками (у них свой слек, и есть общие каналы)
как это все перетащить в спейс? Будет какой-то импортер этого всего с историей или как?
Будут ли плюсы от спейса стоить всех тех телодвижений по переносу процессов существующего проекта?
Причём вопрос не только в функциональности, но и пожалуй в цене.
Для хостинга гит репозиториев оно будет кушать ресурсов больше чем гитлаб или меньше?
Сможет ли оно нормально работать на изолированной от интернета машине? (ну понятно что без всяких зеркаилрований репозиториев из коробки.)
Можно ли в нём отключить все вот эти чатики и так далее?
С одной стороны хочется верить что уж у JetBrains то точно получится нормально сделать всё в одном. С другой стороны пока ни один из таких многоликих проектов не выполняет хорошо всё что умеет, а из за этой многоликости страдает основная функциональность :(
Русский интерфейс имеется?
Вопрос, будет ли широкое тестирование self-hosted версии? Немного страшновато что от одного продукта может полностью зависеть работоспобность компании.
И как будет self-hosted реализован? Как множественные компоненты работающие отдельно или монолитный сервис? Или наподобие gitlab можно будет выбирать какие компоненты выносить на отдельные сервера?
Вопрос, будет ли широкое тестирование self-hosted версии? Немного страшновато что от одного продукта может полностью зависеть работоспобность компании.
Да, будет, конечно, но пока сроков по self-hosted точных нет.
И как будет self-hosted реализован?
Это будет единая инсталляция, которая поставляется как единое решение. После установки все компоненты будут доступны, но их не обязательно все ипользовать одновременно. Можно, например, начать с команд, потом добавить чаты, потом постепенно заводить проекты.
Планируются ли какие-то инструменты для того, чтобы интегрироваться в вики (аддоны в редактор, аддоны во вьюхи, хуки на редактирование)?
nkatson для тестирования котлин кода мокинг используете? mockito vs mockk?
А то подписался на EAP 3 дня назад, и тишина… а хотелось бы потестить
Весь мир уходит от монолита в микросервисы.
Jetbrains — пилим монолитный инструмент.
Возможно этот фарш ещё можно провернуть назад. Мне очень нравилась идея Hub, но она всегда была несколько не полноценной. Там не было именно многих интеграций, которые вы тут запилили, типа профиля пользователя с его отпусками, мессенджерами, базами знаний и тд. Уж если разные версии это такая проблема, то прибейте их гвоздями, типа с чатом версии 2011.1.1 может работать только CI/CD той же версии и тд.
Плюсы когда это разные продукты очевидны. Вот поставил простенькую Wiki и для десятка статей всё работает. Растём? Вот на этот сервак я поставлю CF. Надо больше памяти ему закинуть? Ну на. Надо обновить? Ок, вот на соседнем подниму, потестирую и переключу. Начал тупить чатик? Поменяю его, не обновляя остальное.
Маленьким-компактным командам Space ни к чему, а теперь представьте как большая компания со всего стека должна переехать на это? Мигратор? Да там надо несколько месяцев тестировать всё, чтобы понять что без вот этой маленькой фичи все бизнес процессы ломаются у каких-нибудь юристов.
Делайте нормальные инструменты для каждой сферы и давайте нормальный инструменты интеграции и нормально будет. А то в итоге есть хорошие ножи, отдельно для сыра, отдельно для помидоров, и есть просто железная пластинка, которая вроде как и режет, но плохо.
YT, TC, US всё равно не заменяет эта штука и не догонит уже. А вот свой хостинг репозиториев, чаты, базы знаний, внутренние порталы сотрудников и всякие другие инструменты гармонично интегрируемые в Hub вот чего не хватает чтобы плавно переходить на продукты JB.
Значит ли это что teamcity вообще больше не будет развиваться?
Мне нужна ограниченная часть функционала. Остальной же функционал будет просто мешать. Это вечная проблема «Делаем все для массового потребления».
Не понятно как планировать работу, банально нет нигде никакой привязки ко времени, если мы говорим про создание проекта то логично что нужно планировать задачи и ставить им дедлайн, а в идеале и дату начала работы над задачами.
Да мы можем с помощью чеклистов видеть прогресс проекта но все равно эта информация не дает нам понять когда же проект будет сдан
А так же не видно загрузку команды. Итого получается что для работы над проектом все удобно и в одном месте но для контроля все ли ок успеваем ли во время кто загружен а кто гуляет прийдется использовать еще какой то инструмент?
Есть ли какие то планы по этой части?
Или что рекомендуете использовать в связке для решения данного вопроса?
1. Где можно следить за изменениями что поменялось и добавилось нового в Space?
2. А как создать чат под проект? Сейчас получается что чат автоматом создается по задачам, но логично так же создавать чат под проект что б можно было обсуждать его глобально, в целом не вижу проблем создать его руками но логично было бы иметь возможность автоматической привязки, что б состав участников что в проекте, что в чате, синхронизировался а так же логи по всем изменениям падали в общий чат.
То есть мы получим канал в котором видны любые действия по проекту
— К примеру нет возможности удалить проект
Или если не мигрировать, то будет ли интеграция между продуктами?
P.S. Извиняюсь, что только сейчас ответила, пропустила нотификацию и не видела коммент =(
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
Я подозреваю, что ваш комментарий был проигнорирован потому, что вы в одном комментарии смешали несколько тем. Как минимум тему востребованности продукта Space и тему того, что нужен другой продукт. Если вы не атомарно доносите вещи, то они воспринимаются людьми как неконструктивные и игнорируются.
Еще сильнее они выбивают землю из под ног конструктива, если у них осуждающий формат, а не предлагающий.
Возможно, это не тот способ обратной связи и не та тема, которые они обрабатывают. Когда я писал им в саппорт по вопросу тимсити, мне ответили быстро. Посмотрим.
Встречайте Space — новый продукт JetBrains