opium
@opium
Просто люблю качественно работать

Что вы делали для облагораживания разработки на php?

У заказчика есть довольно посещаемый сайт, используется фреймворк codeigniter, код заливается на php или правится сразу через ssh на сервере из под рута. Собственно куча проблем с разработкой от того что не делаются нужные вещи, нет контроля за исходниками, в код нагадил старый уволенный программист, иногда при обновлении кода сайт ложится, разработчики допускают гигантское количество ошибок.

Первое что сделал смигрировал сайт на новую машину с последними версиями php и apache, заблочил доступ по ssh, дал доступы по ftp, вычистил вредоносный код(не уверен что весь), исправил все небольшие ошибки вылезшие после обновления php с 5.1 до 5.3, с базой mysql теперь работают из под отдельной учетки не из под рутовой. Сразу отмечу что девелопили куча народу и код больше похож на быдло код, разобраться в части ошибок было не просто, код наполнен кучей комментариев с отладочным кодом.

Думаю надо ещё сделать тестовый сервер для обкатки изменений, перевести исходники на github, туда же перевести из экселя роадмап по разработке. Деплоить все на сайт гитом, сперва на тестовый, а потом на продакшен.

Что ещё можно сделать? Как вы девелопите для продакшена на php?
  • Вопрос задан
  • 3695 просмотров
Пригласить эксперта
Ответы на вопрос 10
sHinE
@sHinE
веб-разработчик, php/js/mysql и сопутствующее
Тестирование + документирование еще можно прикрутить. Ну и все это через continuous integration сервер какой-нибудь.
А тестовый сервер (ну или staging), я думаю, обязательно надо.
Ответ написан
p4s8x
@p4s8x
1) Тестовый сервер
Очень часто бывают ситуации, когда разработчик(в частности фрилансер) находится не за своим любимым рабочим местом, а где-то в гостях, в отъезде и т.д.
Когда появляется необходимость исправить баг или внести какие-либо изменения — разворачивать за чьим-то ноутбуком/стационарником все инструменты, ставить денвер, качать все целиком, разворачивать базу. Значительно проще поставить winscp¬epad++ и внести правки на продакшн. С увеличением частоты таких «правок» код превращается в то, что описано выше.
Для решения таких проблем в первую очередь введен регламент — запрета вносить правки на продакшн, но! одновременно с этим допускается работа на тестовом сервере! Все правки, мелкие большие с сервера коммитятся в свн(изучить консольные команды svn для разработчика не составляет проблемы… их нужно 2-3 в такой ситуации) и уже только после этого апдейт на продакшене. Для апдейта на продакшене даже сделан www-скрипт, который позволяет делать апдейт без подключения к ssh и т.д.
Изменения в БД все только через миграции!
Так что делайте тестовый сервер обязательно! ИМХО необходимая вещь любому проекту.

2) Трекер! Писать и общаться через трекер воспитывает и клиента и заказчика.
Мы на томже тестовом развернули редмайн. Позже добавили к нему tikiwiki, в которую пишутся полезные няшечки для других разработчиков и клиента. Трекер также отображает активность разработчиков для клиента. Клиенту приятно посмотреть, что вот была такая ошибка и по её исправлению был сделан такой-то коммит и вон чето поменяли.

3) Проведение рефакторинга. Очень сложно клиенту объяснить, что это такое и зачем он нужен. Почему он должен платить за «переписывание» кода? Пишите сразу правильно, скажет он. Практика показывает, что всетаки можно доказать клиенту необходимость этого действия.

4) Автоматические тесты.
На тестовом сервере далеко не всегда можно увидеть все проблемы- не поломался ли чужой код.
Использование фреймворков позволяют не разводить тотальную быдлятину и обложить код тестами.
Ответ написан
@Disturbed
Зависит от проекта. Юнит тесты (я подозреваю что их нет), Continuous Integration,… Кстати, заказчик то не против будет сорсов на гитхабе? или вы приватный репозиторий собираетесь создавать?
Ответ написан
ainu
@ainu
Сейчас скажу бесполезный совет.
Последнее моё облагораживание привело к переписыванию с нуля. Профит огромный — если писать сразу по плану и правильно, получается быстро, 500 строк быдлокода можно свернуть в 10 строк контроллера/модели в MVC.
Ответ написан
MpaK999
@MpaK999
Буду!
Немного советов от человека, который на CodeIgniter собаку съел.

В CodeIgniter очень хорошая расширяемость, проанализируйте код, найдите общие моменты и сделайте рефакторинг кода, вынесите общие методы из моделей в свои типы моделей (можно унаследовать у MY_Model), с контроллерами так же.

Views файлы надеюсь разбиты на папки контроллеров, если нет, то надо разбить. Весь JS вынести так же в отдельную папку и по своим файлам так же.

Причесать код сведя контроллеры к минимуму действий.

На модели в CodeIgniter есть инструмент тестов, вполне хватающий для тестирования их.
Ответ написан
png
@png
Коллеги, присоединяюсь ко всему, что сказано выше.
От себя добавлю.
unit-тесты на старый код — это бесполезное занятие, т.к. там наверняка быдло код, его качественными тестами покрыть будет крайне трудоемко. я бы сделал так.
1. на весь новые функционал писать unit-тесты. программистам дать для просвещения макконела и что-нибудь по практикам TDD, SOLID, GOF.

2. старый и новый функционал покрыть интеграционными тестами.
Если есть какие-то фоновые взаимодействия, выгрузки и прочее, это можно проверять.
Пользовательский интерфейс тоже можно тестировать автоматизированно.
см. BDD. Пусть в браузере прогоняется автоматически весь функционал сайта.

3. в качестве CI-сервера я использовал hudson. Меня вполне всё устроило.
тот же Jenkins — это его форк

4. за продакшен должен отвечать только один человек.
можно организовать это так. делаем отдельную ветку, или бранч, или вообще отдельный реп.
это как организуетесь.
в него может комитить только один человек. Этот человек делает ревью всего кода перед тем как залить его в продакшен репозиторий.
соответственно этот человек «выпивает мозги» программистам, чтобы всё так было. Ну а случись что, есть за это дело ответственный, с которого спрашивается в первую очередь.

5. на счет www-скрипта — это уж слишком, если б программистов было человек 30 и функционал выкатывался бы каждый день(или хотя бы раз в неделю разными людьми), то да, а так я думаю оно лишнее.
бывают ситуации, когда приходится делать отладку на боевом комитами и www-скриптом. Кто-нибудь из программистов обязательно так сделает…
Ответ написан
Организовал так:
— исходники в репе под Mercurial
— клон репа на тестовом сервере, докрут указывает на нужный каталог
— на продакшен деплой производится capistrano
— если приходится править код в «экстремальных» условиях, то на сервере есть отдельный пользователь тоже со своим клоном репа и установленным capistrano, то есть даже срочная правка по ssh заключается в пулле свежих изменений с основного репа, внесение срочных, коммит в клон, пуш в основной, cap deploy
Ответ написан
@Silver_Clash
У нас так:

Трекер — редмайн, система контроля версия СВН.
Разработка ведется на 3-х серверах разработки на которых работают две команды. Два основных, один на случай если есть параллельные задачи. Все изменения хранятся в СВН. Тестировщики предварительно тестируют экземпляр прямо на серверах разработки. После успешного предварительного тестирования, Хадсон собирает экземпляр на тестовый сервер.
После успешного тестирования, пакет собранный из СВН устанавливается на пре-продакшн частично вручную, частично при помощи sh-скрииптов. После еще одного сокращенного цикла тестирования аналогично устанавливается на продакшн.
К сожалению модульное тестирование не внедрили, не хватает времени.
Ответ написан
png
@png
По поводу wiki.
Заводите в репозитории папку docs и кидаете туда текстовые файлы с описанием. github умеет красиво показывать определенное форматирование.

Но есть вариант лучше, попробуйте GoogleDoc.
Можно даже корпоративный сделать со своим доменом.

плюс по сравнению с wiki
1. одновременное редактирование несколькими пользователями
2. крутая история изменений
3. крутой редакторы, разные форматы офисным данных
4. экспорт данных в разные форматы

короче, такой вариант мне очень нравится ) сам пользуюсь )
Ответ написан
Kuzma
@Kuzma
еще можно добавить удобства работы с разными конфигами для продакшена и девелопмента. чтобы не нужно было после чекаута с githab-а конфиги править

Подробнее: ikuznetsov.blogspot.com/2012/02/blog-post.html
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы