У кого-либо есть рабочий процесс разработки/подготовки/развертывания с php/mysql? [закрытый]

Для меня ... самый простой способ сделать это - использовать JSON.net для десериализации сущности, которая представляет объект, например:

public class Message
{
    public string status { get; set; }
    public string messageid { get; set; }
    public string gsm { get; set; }
}

public class YourRootEntity
{
    public string type { get; set; }
    public string totalprice { get; set; }
    public string totalgsm { get; set; }
    public string remaincredit { get; set; }
    public List<Message> messages { get; set; }
}

И выполните следующее:

YourRootEntity data JsonConvert.DeserializeObject<YourRootEntity>(jsonStrong);
17
задан Zoran Zaric 11 January 2009 в 01:57
поделиться

2 ответа

Вот то, что мы делаем:

  1. Все работают над их проектами в их ответвлении (код, тесты, и т.д.)
  2. , Когда все выглядит хорошим, это объединяется в Соединительную линию
  3. , phpUnderControl восстанавливает Соединительную линию, выполнения весь наш тесты phpUnit, документация сборок, обновленный дб, и т.д.
  4. , Если все, что передает, мы объединяемся в Stable
  5. , Stable полностью восстановлен как Соединительная линия
  6. , Stable вручную продвинут на наш Рабочий сервер

, у Нас есть несколько пользовательских сценариев, которые заботятся о наших обновлениях базы данных и нашем нажатии к Производству. Для нашей базы данных мы сохраняем все дельты в единственной папке, и сценарий проверяет текущий уровень DB по доступным дельтам и, в случае необходимости, применяет их.

Для продвижения Производству у нас есть другой сценарий, который раскрывает все производственные данные и затем выполняет rsync для увеличивания изменений.

Вы не упоминаете, какой уровень управления Вы имеете по серверам, но полный процесс был бы тем же для общей разработки.

12
ответ дан 30 November 2019 в 13:54
поделиться

Я думаю, что все делают эти вещи, немного отличающиеся, в зависимости от точного приложения. Вот наша установка:

Перед выпуском:

  • Все соглашаются /trunk.
  • , Когда мы хотим прокрутить выпуск, мы копируем соединительную линию в /tags/yymmddhhiiss.
  • Мы стабилизируем тег.

, После того как это стабилизируется, мы запускаем развернуть скрипт:

  • На рабочем сервере, контроль новый тег.
  • Берут дамп базы данных.
  • демоны Остановки и закрытие веб-приложение (веб-приложения).
  • Переключатель символьная ссылка /current для указания на недавно проверила тег.
  • Запущенные скрипты миграции.
  • демоны Перезапуска и приложения.

, Если мы должны выставить небольшое изменение быстро, мы объединяем его с текущим тегом, и мы можем затем выполнить намного более простой процесс текущих исправлений в сервере:

  • демоны Остановки и закрытие веб-приложение (веб-приложения).
  • Выполнение svn update
  • демоны Перезапуска и приложения.

Примечание, что существуют определенные инструменты, которые нацелены на структурирование/автоматизацию этих процессов. Phing один, и , Symfony имеет свое собственное пакетная система , который раньше был одиноким проектом, названным pake. И как будто это недостаточно, Платформа Зенда собираются создать их собственный вариант . Это - все действительно определенная путаница, но Phing, вероятно, наиболее широко используется. Можно также использовать что-то конкретное non-php, такой как [1 112] Муравей или Capistrano. Мы просто используем сценарии оболочки, который в основном удовлетворяет ту же потребность.

у Нас также есть непрерывное выполнение сборки, которое проверяет из соединительной линии и запускает все тесты. В настоящее время у нас просто есть основной набор сценариев оболочки, делающих его, но мы рассматриваем для переключения на [1 114] PhpUnderControl или xinc.

Эти миграции шаг, возможно, заслуживает небольшого объяснения. Theese содержит изменения в базе данных, а также другие задачи, которые должны быть выполнены для нового выпуска. Наши миграции немного просты в данный момент; у Нас просто есть папка с набором .php и .sql сценарии и во время миграции, они выполняются в последовательности. Путем мы отслеживаем, которых изменений был выполнен, путем освобождения migrations папка прямо после того, как новый тег был сделан. Вероятно, было бы более умно использовать базу данных для входа, какие изменения были выполнены все же. Нас рассматривают, принимая что-то как [1 116] ruckusing с этой целью.

7
ответ дан 30 November 2019 в 13:54
поделиться
Другие вопросы по тегам:

Похожие вопросы: