Comments 39
Т.е. упрощая все до одного предложения Вы взяли почти все Atlassian продукты и засетапили Jenkins.
А как у Вас организована система общения в коллективе (HipChat \ Slack \ Jabber \ etc..)?
А продуктивность как учитываете?
И случаем не смотрели в сторону TeamCity?
А как у Вас организована система общения в коллективе (HipChat \ Slack \ Jabber \ etc..)?
А продуктивность как учитываете?
И случаем не смотрели в сторону TeamCity?
Вот кстати насчёт общения — больной вопрос. Только что посчитал — телеграм, скайп, слак и почту я пользую ежедневно. Понятно что почту врядли получится заменить, но всё остальное совместить внутри команды можно было бы.
Пробовали разные системы, но пришли к выводу, что всем удобнее группы в скайпе: весь проект, программисты, тестировщики и лиды.
Jira благодаря «Automated Log Work for JIRA» автоматом логирует время. А у «WorkLog» отличные визуальные отчеты. Вот-вот опубликую вторую часть, там об этом есть.
TeamCity — не изучал. Но спасибо за наводку, посмотрю.
Jira благодаря «Automated Log Work for JIRA» автоматом логирует время. А у «WorkLog» отличные визуальные отчеты. Вот-вот опубликую вторую часть, там об этом есть.
TeamCity — не изучал. Но спасибо за наводку, посмотрю.
сколько это все денег выходит то?
Улыбнулся картинке «Стек Atlassian + Jenkins». Сами напоролись на те же грабли, Bamboo крайне неудачный сырой продукт, что удивительно, по сравнению с другими замечательными продуктами Atlassian. У нас только на этой картинке вместо Jenkins — TeamCity :)
А у меня обратное мнение. Пользуемся Bamboo в связке с Jira-Confluence-Bitbucket. Если честно после Jenkins, просто раем показался. :) TeamCity не пробовал пощупать по настоящему, поэтому не могу сказать за его удобство.
Что сделать в Bamboo проще:
— разделение стадий сборки и деплоя
— удобный и понятный интерфейс (субъективно)
— контроль версионности
— git-workflow из коробки
Минус я вижу только один — действительно маленькое сообщество и небольшое количество плагинов. Хотя на самом деле написать свой плагин дело пары тройки дней. Мы, например, написали плагин деплоя сборки на сервера Amazon AWS через OpsWorks. Работает вполне прилично.
Что сделать в Bamboo проще:
— разделение стадий сборки и деплоя
— удобный и понятный интерфейс (субъективно)
— контроль версионности
— git-workflow из коробки
Минус я вижу только один — действительно маленькое сообщество и небольшое количество плагинов. Хотя на самом деле написать свой плагин дело пары тройки дней. Мы, например, написали плагин деплоя сборки на сервера Amazon AWS через OpsWorks. Работает вполне прилично.
Нас тоже привлекли такие фичи, как разделение на сборку и деплой, ручные этапы сборки, красивый интерфейс и прочее. Ели сравнивать с Jenkins, (особенно с безплагинным), то преимущество налицо. Но у нас на паре проектов был ТимСити и сравнивать приходилось именно с ним. Например, отсутствие в Bamboo шаблонов просто убивает. Если у меня 20 билд-планов и я хочу добавить (или изменить шаг) во всех — я должен это проделать ручками в каждом из них. В Jenkins, кстати есть плагин для delivery pipeline, который как раз делит на фазы build-test-deploy.
В итоге, как я написал, Bamboo сырой. Он вроде бы хороший, но блин, вот этого нет, вот этого нет, вот это через задницу… и так везде. Ощущение недоделки. ТимСити в том отношении намного приятнее. Jenkins нужно тщательно готовить, и я не пробовал погружаться в него с головой, но коллеги говорят, что плагины есть для любых процессов и вообще всего на свете.
В итоге, как я написал, Bamboo сырой. Он вроде бы хороший, но блин, вот этого нет, вот этого нет, вот это через задницу… и так везде. Ощущение недоделки. ТимСити в том отношении намного приятнее. Jenkins нужно тщательно готовить, и я не пробовал погружаться в него с головой, но коллеги говорят, что плагины есть для любых процессов и вообще всего на свете.
Так и не смог понять из статьи три вещи:
- Какие продукты вы разрабатываете?
- Какие языки и технологии применяются?
- Зачем эта статья здесь?
1. Ну это к делу не относится. Но это и не секрет. Разрабатываем всевозможные web-системы. Соц сети, онлайн торги, платежные системы, почтовые системы и т.д. и т.п.
2. Пишем в основном на PHP+Postgresql, но бывают и исключения.
3. Правильно построенный workflow здорово облегчает жизнь всем участникам процесса разработки. И вот один из способов автоматизировать этот процесс по максимуму.
2. Пишем в основном на PHP+Postgresql, но бывают и исключения.
3. Правильно построенный workflow здорово облегчает жизнь всем участникам процесса разработки. И вот один из способов автоматизировать этот процесс по максимуму.
А почему ревью не делаете прямо на битбакете в пулл реквесте?
И про сумму расскажите, а то стек хороший, но денег просит при том, что есть аналоги схожей функциональности, тот же гитлаб имеет и вики, и битбакет заменит, и трекер, и код ревью проводить можно.
И про сумму расскажите, а то стек хороший, но денег просит при том, что есть аналоги схожей функциональности, тот же гитлаб имеет и вики, и битбакет заменит, и трекер, и код ревью проводить можно.
В вашем workflow используется пулл реквест. У нас — нет. У нас все программисты работают в dev ветке и тимлид раз на версию это все сливает в мастер ветку.
Честно говоря я так и не понял до сих пор как быть с тестированием в модели пулл реквеста.
GitLab как бы имеет и трекер и вики… но в функциональности они вообще рядом с Jira и Confluence не стоят. Читайте ЧАСТЬ 2. Такое на GitLabe не настроить.
Честно говоря я так и не понял до сих пор как быть с тестированием в модели пулл реквеста.
GitLab как бы имеет и трекер и вики… но в функциональности они вообще рядом с Jira и Confluence не стоят. Читайте ЧАСТЬ 2. Такое на GitLabe не настроить.
У нас все программисты работают в dev ветке и тимлид раз на версию это все сливает в мастер ветку.
Всё, понял, недочитал сначала. То есть git использовать вы не умеете. На этом можно тему с вашим flow закрывать, к сожалению…
Для тестирования в модели с пулл-реквестом разворачивается отдельный стенд для каждой тестируемой ветки. Делается это как правило автоматизированными средствами (тем же jenkins'ом без проблем). Таким образом, в основную ветку изменения попадают только после тестирования.
Вот и получается, что тестить приходится дважды. А для качественных тестов порой времени тратится в несколько раз больше чем на разработку.
Наши тестировщики проводят всевозможные виды тестирования, которые отнимают ну очень много времени, но за то покрывают всё. Потому тратить время на два таких тестирования не целесообразно. Либо надо иметь тестировщиков в два раза больше чем программистов. Ну или тестировать только позитивным тестированием.
Наши тестировщики проводят всевозможные виды тестирования, которые отнимают ну очень много времени, но за то покрывают всё. Потому тратить время на два таких тестирования не целесообразно. Либо надо иметь тестировщиков в два раза больше чем программистов. Ну или тестировать только позитивным тестированием.
Два раза, говорите? Вот обычный чек-лист для тестирования:
Весь этот список на workflow с ветками ложится следующим образом:
Итого: много небольших «сеансов тестирования» во время активной разработки, большое тестирование перед релизом. Весь процесс тестирования удобно и итеративно автоматизируется. В конце концов, регрессия и интеграция тестируются автоматизированно.
- тест разработчиком («протыкать» реализованный функционал, может быть smoke-test примитивный)
- модульное тестирование (unit-тесты) разработчиком и автоматизированно
- тест тестировщиком соответствия реализации заданию (этот этап все называют по-разному: функциональное, подтверждающее)
- тестирование тестировщиком на скрытые баги/уязвимости, обычно совместно с предыдущим пунктом
- регрессионное тестирование — комплексная проверка функционала, который до этого момента корректно работал («ничего не сломалось»)
- интеграционное тестирование — проверка, что связанные системы все еще нормально работают нашим модулем
- приемочное тестирование
Весь этот список на workflow с ветками ложится следующим образом:
- отдельная ветка тестируется разработчиком, запускаются модульные тесты, ветка передается на функциональное тестирование — пройтись по задаче, проверить, что кнопки на своих местах, нажимаются, заказанный функционал работает (это не тестирование всей системы)
- перед релизом таких веток набирается много, они после функционального тестирования сливаются в релизную ветку (если релизы линейные — ваш dev) и проводится регрессионное тестирование всей системы, интеграционное тестирование
Итого: много небольших «сеансов тестирования» во время активной разработки, большое тестирование перед релизом. Весь процесс тестирования удобно и итеративно автоматизируется. В конце концов, регрессия и интеграция тестируются автоматизированно.
И это вы еще забыли автоматическое функциональное и регресс-тестирование, например Selenium. У нас, например, отдельный сервер отведен под тестовый стенд с Selenium. Тесты автоматом запускаются после сборки каждого шота, билда и препродакшна, итого каждая задача три раза проходит набор автотестов.
И это только малая часть комплекса работ по QA. А тут нам говорят, что «два раза тестировать — это чересчур»…
И это только малая часть комплекса работ по QA. А тут нам говорят, что «два раза тестировать — это чересчур»…
ОК, коллега. Второй вопрос вы разъяснили, спасибо. Первый — что-то написали, спасибо и на том.
А вот по третьему — по-прежнему полная непонятка. Какой git flow используете, «git flow» или что-то свое? Почему именно такая система веток вам приглянулась? Как строите изолированные стенды? Что именно работает в качестве сценария сборки?
Статья не содержит основной ценности, how-to. И очень смахивает просто на отписку. Мол у нас — флоу. И что?
А вот по третьему — по-прежнему полная непонятка. Какой git flow используете, «git flow» или что-то свое? Почему именно такая система веток вам приглянулась? Как строите изолированные стенды? Что именно работает в качестве сценария сборки?
Статья не содержит основной ценности, how-to. И очень смахивает просто на отписку. Мол у нас — флоу. И что?
Возможно из-за перехода с svn, но мне кажется, что наш флоу удобнее.
1. У программиста не бывает задач дольше дня — нет смысла делать много комитов по одной задаче.
2. они так или иначе влияют на правки другого программиста — как тестировать? Опишите, пожалуйста, как тестируют у вас. И вообще есть тестировщики?
3. очень часто исправляются одни и те же файлы одновременно несколькими программистами — мержи и в нашем случаи неизбежны, но в случае с ветками 100% будут конфликты.
4. Работа всего коллектива не останавливается в случае отсутствия мастера.
Как я уже писал в части 2, любой программист может срочно исправить багу, и любой тестировщик может срочно собрать исправления и протестировать.
Пул реквест мы пробовали внедрять несколько раз, но ниразу не взлетел.
1. У программиста не бывает задач дольше дня — нет смысла делать много комитов по одной задаче.
2. они так или иначе влияют на правки другого программиста — как тестировать? Опишите, пожалуйста, как тестируют у вас. И вообще есть тестировщики?
3. очень часто исправляются одни и те же файлы одновременно несколькими программистами — мержи и в нашем случаи неизбежны, но в случае с ветками 100% будут конфликты.
4. Работа всего коллектива не останавливается в случае отсутствия мастера.
Как я уже писал в части 2, любой программист может срочно исправить багу, и любой тестировщик может срочно собрать исправления и протестировать.
Пул реквест мы пробовали внедрять несколько раз, но ниразу не взлетел.
Не бойтесь конфликтов. Бойтесь, когда мерж проходит слишком гладко…
Повторю еще раз свою основную мысль — если вы не изолируете код отдельных тасков в отдельные ветки, вы не умеете использовать гит. Он вам просто не нужен, вы его не смогли понять.
Да, у меня есть и тестировщики (много) и разработчики (еще больше). А еще у меня есть понимание, что разработчик вообще не должен думать о флоу, сборках и прочем. Его задача — коммитить и пушить, а все остальное у меня автоматизировано. Как именно — лучше почитайте статьи Badoo, у них это описано ( и сделано) лучше.
Повторю еще раз свою основную мысль — если вы не изолируете код отдельных тасков в отдельные ветки, вы не умеете использовать гит. Он вам просто не нужен, вы его не смогли понять.
Да, у меня есть и тестировщики (много) и разработчики (еще больше). А еще у меня есть понимание, что разработчик вообще не должен думать о флоу, сборках и прочем. Его задача — коммитить и пушить, а все остальное у меня автоматизировано. Как именно — лучше почитайте статьи Badoo, у них это описано ( и сделано) лучше.
В то время я заметил Stash. В чистом виде под линукс я, к сожалению, его не нашёл, за то поставил его в составе Bitbucket.
У меня сложилось впечатление, что Вы толи впопыхах разбирались, толи я не знаю что подумать.
Дело в том, что Stash и Bitbucket Server это один и тот же продукт. Просто буквально недавно атлассиан переименовали его из первого во второе. И соответственно я не представляю как Вам удалось поставить Stash в составе Bitbucket :)
Аналогично про код-ревью.
Рекомендую поглубже изучить инструменты, которыми пользуетесь.
Все немного не так. Про стеш я рыл много, но толкового описания не нашёл. Он и сейчас есть на сайте атласиана для скачивания, но только под Винду. У меня не было желания его ставить, чтобы удовлетворить любопытство. Когда я установил Bitbucket, я подумал, что стеш был просто репозиторием, а тут ещё и понятие проектов появилось…
Так как при подключении репозиториев к Fisheye, они светились именно как стеш репозитории, то я и сделал вывод, что стеш просто обернули в новую обертку.
Так как при подключении репозиториев к Fisheye, они светились именно как стеш репозитории, то я и сделал вывод, что стеш просто обернули в новую обертку.
Он и сейчас есть на сайте атласиана для скачивания, но только под Винду.
Единственное место где можно скачать Stash — это архив ( www.atlassian.com/software/bitbucket/download-archives ).
И там, если посмотреть, каждая версия идёт в 5 вариантах: ZIP Archive, Windows 64bit Installer, TAR.GZ Archive, Mac OS X Installer и Linux 64bit Installer.
то я и сделал вывод, что стеш просто обернули в новую обертку
Даже ссылка www.atlassian.com/software/stash редиректит на www.atlassian.com/software/bitbucket/server, где кстати в самом верху страницы большими белыми буквами на голубом фоне написано «Stash is now called Bitbucket Server».
Не знаю, честно говоря, как надо было читать чтобы сделать такой вывод.
P.S. мы в проекте используем активно почти весь атлассиановский стек: Jira, Confluence, Bamboo, Bitbucket server, Crucible/FishEye. Администрированием и настройкой последних трёх полностью занимаюсь сам. Можно сказать собаку съел =) Для Stash писал плагины (надо их, кстати, под bitbucket адаптировать). В бамбу настроены разноплановые тесты, сборки и деплои web-проектов. Это я не хвастаюсь, не подумайте. Это я к тому, что смею считать, что довольно неплохо разбираюсь в атлассиановском софте. Поэтому и Ваши утверждения несколько удивили меня.
А зачем Crowd если есть LDAP или AD?
Jira — 2 ядра, 2ГБ ОЗУ
Теперь все эти продукты летают, и зависаний, как раньше, нет.
Серьезно? Она уже не Resource Hog?
Ну повторюсь, что я не админ. Не исключено, что оно жрёт ресурсы сверх моих выделенных.
Но по графикам видно, что тяжелее всех именно Confluence.
Jira как то вообще замечательно себя ведёт.
Но по графикам видно, что тяжелее всех именно Confluence.
Jira как то вообще замечательно себя ведёт.
JIRA умеет настраивать сколько угодно ролей, вы их сами создаете. Я бы поставил побольше ролей — их удобно использовать потом для нотификаций, для прав доступа, в workflow удобно их можно использовать.
У нас есть нужда показывать заказчикам из JIRA не то что на самом деле. По крайней мере частично.
+ СRM (client relationship management)
+бухгалтерия
Что посоветуете?
+ СRM (client relationship management)
+бухгалтерия
Что посоветуете?
Sign up to leave a comment.
Автоматизация workflow небольшой команды разработки (Часть 1)