Поделимся опытом миграции между разными типами инстансов. Продемонстрируем возможные варианты автоматизации на базе Atlassian Jira, которые были разработаны и успешно внедрены в бизнес процессах iFellow. Представим своё видение и обсудим инструментарий справочников в Jira. Поделимся опытом интеграции Jira и Blockchain
Цель
Продемонстрировать аудитории возможности продукта Atlassian Jira по автоматизации бизнес процессов и интеграции с различными системами.
Задачи
Представить продукт Atlassian Jira не только как инструмент для разработки Рассмотреть успешные практики автоматизации и показать используемые инструменты Рассказать о возможностях миграции
Описание секции
Наша команда имеет многолетний опыт разработки и внедрения решений на базе: #Jira #Confluence #Управление проектами #Blockchain #Плагины #Groovy, #Script Runner, готова поделиться своим опытом и компетенциями в стеке Atlassian.
Истории о миграции в облака и обратно, и переходы на Data center
Таранченко Владимир (iFellow)
Готовим справочники Jira вместе.
Кондаков Александр (iFellow)
Специалист по интеграциям на рынке финтех проектов с опытом более 5-ти лет Blockchain и Jira. История одной интеграции глазами разработчика
Доклад:
Сделаем обзор blockchain-решений. Расскажем о своём опыте интеграции blockchain Ethereum и Jira на примере реализованного проекта по маршрутизации сервисных заявок на обслуживание. Подсветим "интересные" моменты интеграции - библиотеки, смарт-контракты, abi. Обсудим использование blockchain-технологий при построении бизнес-процессов.
Кузнецов Михаил (iFellow)
Хотите приготовить Jira - спросите нас как. Рецепты автоматизации.
Тезисы:
Если вы не любите Jira, то вы просто не умеете ее готовить. Как мы автоматизировали все и вся в iFellow.
Error get alias
Error get alias
Error get alias
Error get alias
Error get alias
Error get alias
Error get alias
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.