Я не предлагаю — просто поинтересовался. Вы ж просили критики ;)
А на счёт простоты — мне кажется магические методы её как раз и убивают (усложняют восприятие кода), хотя иногда без них никуда.
не будет ли это стрельбой их пушек по воробьям в случае веб-приложений на PHP?
Для php есть CruiseControl+phpUnderControl.
ИМХО, гонять тесты при каждом коммите — это перебор и ненужные задержки.
У нас тесты запускаются по расписанию, как правило, ночью.
Главная проблема, по-моему, лишние телодвижения: вместо «сделал->залил->проверил->поправил->залил->проверил->закоммитил» нужно будет «сделал->закоммитил->»выкатил"->проверил->поправил->закоммитил->«выкатил»->проверил" и чем больше итераций «поправил->проверил», тем больше «оверхид»
А как же контроль версий? Или вы пользуетесь сугубо Local History?
И ещё один вопросик — к чему такие сложности вообще, или иными словами, почему нельзя dev'ить локально?
Если код готов к релизу, что ему делать на staging? Релизить надо! :)
В основном, отдаётся на откуп админам, чтоб убедиться что ничего не рухнет за выходные :) И для показа заказчику, если ему интересно.
У нас релиз производится каждые 2-е недели, и «готов к релизу» — имелось в виду, что все обозначенные задачи выполнены и всякие-разные автоматизированные тесты пройдены.
Если упростить, то схема такова:
новый спринт => новая ветка => слияние в транк => staging => production
То есть, вся разработка ведётся в ветках, которые затем сливаются в транк.
Хотя здесь всё зависит от применяемых в команде практик разработки — вариантов уйма.
или имеете в виду что и работать надо на удаленном?
Именно. Если в этом есть насущная необходимость (хотя мне сложно её представить).
, но у нас почему-то не принято, чтобы какие-то «левые» файлы потенциально были доступны по http даже в локалке.
А какие у вас бывают «левые» файлы, кроме служебных файлов используемой IDE?
К тому же, если править файлы по FTP — не проблема, то почему править по SSHFS — проблема?
ИМХО, FTP при разработке нафиг не нужен — лишний бардак.
На production- и staging-сервера литься итак должно с транка. А для dev'a есть либо localhost, либо SSHFS.
А на счёт простоты — мне кажется магические методы её как раз и убивают (усложняют восприятие кода), хотя иногда без них никуда.
Разве есть правила, запрещающие публиковать перевод?
Или вас это не устраивает по каким-то другим причинам?
По PostgreSQL на русском языке я видел всего 2-е книги (или 3), которые были далеко не фонтан.
ИМХО, гонять тесты при каждом коммите — это перебор и ненужные задержки.
У нас тесты запускаются по расписанию, как правило, ночью.
И ещё один вопросик — к чему такие сложности вообще, или иными словами, почему нельзя dev'ить локально?
А какая проблема зайти на dev-сервер и выкатить код из VCS? Эту операцию же можно «автоматизировать».
У нас релиз производится каждые 2-е недели, и «готов к релизу» — имелось в виду, что все обозначенные задачи выполнены и всякие-разные автоматизированные тесты пройдены.
Если упростить, то схема такова:
новый спринт => новая ветка => слияние в транк => staging => production
То есть, вся разработка ведётся в ветках, которые затем сливаются в транк.
Хотя здесь всё зависит от применяемых в команде практик разработки — вариантов уйма.
Именно. Если в этом есть насущная необходимость (хотя мне сложно её представить).
А какие у вас бывают «левые» файлы, кроме служебных файлов используемой IDE?
К тому же, если править файлы по FTP — не проблема, то почему править по SSHFS — проблема?
1. Капитан говорит, что SSHFS = FS over SSH, not SFTP.
2. SSHFS позволяет монтировать удалённые файловые системы, как локальные.
На production- и staging-сервера литься итак должно с транка. А для dev'a есть либо localhost, либо SSHFS.