Каждая задача — ветка в гите. Билд — тоже ветка, куда мержатся задачи из всех веток, которые протестированы. Как только разработчик запушил ветку, и нажал «Готово» в таск-трекере, от него больше ничего не зависит. Как только тестировщики проверят задачу (читай — выгрузят к себе ветку и посмотрят, что все работает, и нажмет кнопку «Протестировано»), она автоматически будет смержена в ветку следующего билда и вместе с ним уедет на продакшен.
1. На сколько я знаю, phpcs умеет только указывать на ошибки в код-стайле, но не умеет сам их форматировать. Когда мы вводили четкий стандарт кодирования, обязательным условием было наличие утилиты, которая бы сама умела правильно форматировать код. Иначе это была бы ужасная пытка для разработчиков. Более того, наша утилита проверяет и форматирует только тот код, который был затронут в коммите.
2. Он быстрый, простой и его не так сложно допиливать под свои нужды. Нам он нужен в первую очередь, чтобы смотреть дифф ветки и оставлять комментарии к строкам. Мы пробовали более тяжелые решения, например, FishEye но его так и не получилось по-нормальному внедрить, плюс он достаточно долго работал на нашем репозитории.
В кратце, раньше у нас был svn, потом поставили git-svn, а потом по-командно перевелись на git. До сих пор у нас еще осталось несколько репозиториев на svn, которые по-тихоньку переводим на git.
30 минут стоя получается или у вас сидячий стенд-ап митинг?
Мне кажется очень долго. Детальные вопросы можно позже обсудить, а чтобы понять картину происходящего 5-10 минут должно хватать. У меня был опыт, когда каждому давали минуту-две по секундомеру, и вполне укладывались.
Редис, как и любой другой инструмент, надо использовать с умом. У моих коллег бывали случаи, когда машина уходила в своп при сбросе данных на диск (хранили сессии). Подозреваю, что плохо сконфигурировали этот момент. Было дело, сам лично клал ферму фронтендов выборкой ключей по маске (примерно так — KEYS posts:*). А вообще, редис действительно очень удобен, и им приятно пользоваться.
Думаю, в такой ситуации, когда машины забиты под завязку, в первую очередь стоит задуматься об оптимизации или расширении парка. Поставить пинбу будет вполне логичным решением, для поиска узкого места :)
Она отправляет данные по завершению скрипта, когда пользователь уже получил что хотел. Поэтому она может осуществлять отправку сколь угодно долго, и это никак не повлияет на время отклика.
Это будет похоже на то, как в пробках народ струйками пускается друг за другом в переулки, лишь бы объехать затор :) Мне кажется, должна быть отчасти централизованная система, иначе не избежать диверсий от «пропатченых» авто и ошибок ПО от разных производителей.
2. Он быстрый, простой и его не так сложно допиливать под свои нужды. Нам он нужен в первую очередь, чтобы смотреть дифф ветки и оставлять комментарии к строкам. Мы пробовали более тяжелые решения, например, FishEye но его так и не получилось по-нормальному внедрить, плюс он достаточно долго работал на нашем репозитории.
В кратце, раньше у нас был svn, потом поставили git-svn, а потом по-командно перевелись на git. До сих пор у нас еще осталось несколько репозиториев на svn, которые по-тихоньку переводим на git.
Смотрите Example #2
Мне кажется очень долго. Детальные вопросы можно позже обсудить, а чтобы понять картину происходящего 5-10 минут должно хватать. У меня был опыт, когда каждому давали минуту-две по секундомеру, и вполне укладывались.