Странноватый подход, как мне кажется. Говорят, что если билд не бывает красным, значит CI бесполезен в данном процессе.

Почему когда начинаешь говорить про эффективность, сразу все передергивают, будто бы ты говорил про дешевизну независимо от качества?

Клиент приходит с проблемой, девелопер предлагает решение. Если эта проблема решается лучше без автотестов, но девелопер «уважает себя» и не хочет ее делать без автотестов, то это плохой девелопер. Не понимаю, откуда взялось «спрашивать у клиента».

«помогает бизнесу клиента» != «клиент одобряет»

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

Интересный вопрос. Я только что понял, что просто поменять местами определения у вас не получится =) Не назовешь тесты на отправку email функциональными никак.

Для сложной логики есть юниттесты, мы ж не про них говорим сча.

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

В свое время был очень успешный опыт разработки проекта так: QA писали сценарии на Gherkin, а девелоперы их имплементили вместе с имплементацией фичи. Работало просто отлично. Команда из 15 девелоперов и 4 QA, деплоили проект на прод два раза в неделю. На подготовку релиза у команды QA уходило 2 часа (на ручное тестирование не покрытого автотестами функционала).

Никогда не удавалось увидеть в проекте трудоемкость тестов в 10-20% от всей стори. Если бы это было так, никто бы никогда не спорил об их целесообразности, а просто делали бы и не парились. Мои субъективные наблюдения скорее приближают эту цифру ближе к 50% — половина код и половина тесты. Что не делает их менее важными.

Вообще, это интересно, что никто не жалуется. Может быть проблемы есть только у нас в PHP+Symfony2… Я попытаюсь подготовить тестовый стенд на днях, который это показывает.

Прикол докера в том, что после каждой команды Dockerfile результирующий контейнер кешируется. Т.е. если у вас был такой Dockerfile

RUN apt-get update
RUN apt-get install package1 package2

а поменялся на такой

RUN apt-get update
RUN apt-get install package1 package2 package3

то при сборке следующей он возьмет тот контейнет, который создался в прошлый раз после apt-get update и накатит на него apt-get install package1 package2 package3. Вы можете сделать по-другому:

RUN apt-get update
RUN apt-get install package1 package2
RUN apt-get install package3

Тогда при сборке он возьмет состояние после RUN apt-get install package1 package2 и накатит на него только apt-get install package3.

Если у вас было

RUN command1
ADD directory or file
RUN command2

то при следующей сборке docker посчитает хеш добавленных в ADD файлов, и будет выполнять RUN command2 только если в них что-то поменялось. Т.о. я прихожу к такому предпочитаемому формату Dockerfile

RUN install and configure all server software (типа поставить интерпретатор и fcgi-демон для нужной технологии)
ADD vendors config (у нас в PHP это composer.json + composer.lock, в nodejs это будет package.json в каждой технологии свои)
RUN install vendors (composer install, npm install etc)
ADD static files (js, img, css, scss etc)
RUN compile static files (minify js css, etc)
ADD all source code

Т.о. получается, что при небольшом изменении кода, если это не затрагивает статику и вендоров, контейнер будет билдиться практически моментально (и соответственно деплоиться тоже, т.к. при деплое докер загрузит только изменения, связанные с добавлением других source файлов). Если вы измените JS, то билд будет немного дольше — нужно будет перекомпилировать все JS. И только если измените список вендоров, вам придется перекачивать этих вендоров заново.

Отдельный контейнер для СУБД, отдельный контейнейр чисто для VOLUME файлов данных. Контейнер СУБД юзает volume из контейнера данных. Если надо бэкапиться — запускаете отдельный контейнер, который юзает этот же volume из контейнера данных, и внутри этого нового контейнера запускаете бэкап.

Работать на ненастроенной IDE незачем. Но не все используют продукты JetBrains, как минимум потому что не все готовы платить за них деньги. А если вдруг кто-то из команды захочет Vim или Emacs использовать в работе? Поэтому я считаю, что подход «заливка по SFTP» хотя и может иногда хорошо работать, но подходит далеко не всем.

Стандартный режим работы с Vagrant: вы делаете vagrant up, поднимается виртуалка, провиженится, и ваша папка маунтится в /vagrant в гость, откуда уже работает ваш проект. Т.о. любой девелопер на любой машине может сделать vagrant up, и этого будет достаточно для того, чтобы запустить проект с нуля. Если вы заливаете файлы через SFTP через IDE, то в вашем процессе разворачивания проекта появляется звено «правильно настройте правильную IDE», чего я бы хотел, например, избежать в своих проектах.

Вы и git через IDE используете, получается?

Для веб-девелопера в первую очередь имеет значение производительность shared-папок, т.к. весь код, который запускается, лежит в этой shared-папке. И вот стандартный VirtualBox shared folders иногда вообще абсолютно не подходит для работы (некоторые фреймворки могут по 10 секунд грузить страницу из такой папки), девелоперы пытаются что-то предпринимать типа nfs или rsync (привет, сложности на Windows хостах, да и на макоси у меня nfs глючит с debian хостом), либо совершенный отказ от shared folders (привет сложности с разворачиванием и прощай простой vagrant up). А как у вас с производительностью shared folders?

А какой профит для девелопера от перехода с VirtualBox+vagrant на Parallels+vagrant? Или это имеет смысл только если все-равно используешь Parallels, чтобы запускать Windows приложения на OSX?

Есть руль — виноват тот, кто сидит на месте водителя в беспилотном автомобиле. Нет руля — виноват автомобиль. Поэтому

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

Никаких проблем.