el_script: конечно.
Что у нас было: gitflow, 5 разработчиков. Пул-реквесты, тянущиеся до недели. Деплой раз в неделю.
Что мы сделали: покрыли самые рискованные/важные классы юнит-тестами.
Как сейчас: все работают в одной ветке, назовем её mainline. Перед написанием когда желательно удостовериться что этот кусок кода покрыт тестами. Вместо feature-branch у нас feature-bits/feature toggle. То есть любое изменение оборачивается в условие "если этот флаг включен в файле, тогда выполняй новый код". Соответственно если проходят все тесты, изменение становится сразу доступным на DEV и STG. Релизиться можно от любого состояния этой главной метк, прошедшего тесты (у нас – ежедневно). По-умолчанию флаг выключен на PRD. Как только QA скажут, что все работает хорошо (а они могут посмотреть как код работает с включенным флагом и без и сравнить), то мы включаем флаг на PRD, где он живет неделю, затем мы вычищаем код. Ревью проходит перед релизом на прод двумя релиз инженерами которые проверяют что все условия соблюдены: флаг можно выключить, новый код покрыт тестами. Если что-то пошло не так на проде, флаг выключается (а не версия откатывается) за секунды.
Ну и ссылки:
* paulhammant.com/2013/04/05/what-is-trunk-based-dev...
* www.amazon.com/dp/0321601912?tag=contindelive-20
* martinfowler.com/articles/continuousIntegration.html
* martinfowler.com/bliki/FeatureToggle.html
> Не слишком простой способ?
Не знаю, что ответить. Это сарказм? Можно еще number_format использовать.
> как получиось 59.556?
Я проверял на '59.5555'...
> В пароле символ | не встречается
Если пароли придумают сами пользователи, такой сценарий стоит учесть.
> Про добавление в конец $textareaValue /n не понял, что вы имели ввиду
Я не знаю, откуда берется строка в $textareaValue, но представьте, что она может оканчиваться на /n, как в моем примере.
> Про code-style - Phpstorm сам выставляет tab'ом
Тогда в PHPStorm выберите в меню Code > Reformat Code на весь файл.
maxclax:
> 6 человек один раз у себя установит MAMP, через GIT подтянет все файлы для работы и все.
а так же настроит виртуальный хост, поставит необходимые расширения, настроит базу, поставит какое-то еще дополнительное необходимое ПО.
В случае с vagrant, вы просто запустите команду vagrant up и он все сделает за вас. Так же вы получите окружение, максимально соответствующее продакшену.
Что у нас было: gitflow, 5 разработчиков. Пул-реквесты, тянущиеся до недели. Деплой раз в неделю.
Что мы сделали: покрыли самые рискованные/важные классы юнит-тестами.
Как сейчас: все работают в одной ветке, назовем её mainline. Перед написанием когда желательно удостовериться что этот кусок кода покрыт тестами. Вместо feature-branch у нас feature-bits/feature toggle. То есть любое изменение оборачивается в условие "если этот флаг включен в файле, тогда выполняй новый код". Соответственно если проходят все тесты, изменение становится сразу доступным на DEV и STG. Релизиться можно от любого состояния этой главной метк, прошедшего тесты (у нас – ежедневно). По-умолчанию флаг выключен на PRD. Как только QA скажут, что все работает хорошо (а они могут посмотреть как код работает с включенным флагом и без и сравнить), то мы включаем флаг на PRD, где он живет неделю, затем мы вычищаем код. Ревью проходит перед релизом на прод двумя релиз инженерами которые проверяют что все условия соблюдены: флаг можно выключить, новый код покрыт тестами. Если что-то пошло не так на проде, флаг выключается (а не версия откатывается) за секунды.
Ну и ссылки:
* paulhammant.com/2013/04/05/what-is-trunk-based-dev...
* www.amazon.com/dp/0321601912?tag=contindelive-20
* martinfowler.com/articles/continuousIntegration.html
* martinfowler.com/bliki/FeatureToggle.html