Как понять, что развертывание переходит в Мерзавце

Я хочу дать второй ответ с совершенно другим подходом.

Вероятно, лучший и наиболее безопасный способ сделать это - просто выполнить простой статический подготовленный оператор и разрешить обработку пустых параметров вплоть до SQL:

$sql_update = <<<_SQL_

  UPDATE 
    `users`
  SET
    `km_user_first_name`      = COALESCE(NULLIF(?, ''), `km_user_first_name`      ),
    `km_user_last_name`       = COALESCE(NULLIF(?, ''), `km_user_last_name`       ),
    `km_user_address`         = COALESCE(NULLIF(?, ''), `km_user_address`         ),
    `km_user_city`            = COALESCE(NULLIF(?, ''), `km_user_city`            ),
    `km_user_city_prov`       = COALESCE(NULLIF(?, ''), `km_user_city_prov`       ),
    `km_user_postcode`        = COALESCE(NULLIF(?, ''), `km_user_postcode`        ),
    `km_user_email`           = COALESCE(NULLIF(?, ''), `km_user_email`           ),
    `km_user_website`         = COALESCE(NULLIF(?, ''), `km_user_website`         ),
    `km_user_telephone`       = COALESCE(NULLIF(?, ''), `km_user_telephone`       ),
    `km_user_mobile`          = COALESCE(NULLIF(?, ''), `km_user_mobile`          ),
    `km_user_fiscalcode`      = COALESCE(NULLIF(?, ''), `km_user_fiscalcode`      ),
    `km_user_document`        = COALESCE(NULLIF(?, ''), `km_user_document`        ),
    `km_user_document_number` = COALESCE(NULLIF(?, ''), `km_user_document_number` ),
    `km_user_document_exp`    = COALESCE(NULLIF(?, ''), `km_user_document_exp`    ),
    `km_user_birth_place`     = COALESCE(NULLIF(?, ''), `km_user_birth_place`     ),
    `km_user_birth_date`      = COALESCE(NULLIF(?, ''), `km_user_birth_date`      )
  WHERE
    `user_id` = ?
  ;

_SQL_;

$stmt = $db_user_conn->prepare($sql_update);

mysqli_stmt_bind_param
(
  $stmt,  'ssssssssssssssssi',

  $form_data['km_user_first_name'],
  $form_data['km_user_last_name'],
  $form_data['km_user_address'],
  $form_data['km_user_city'],
  $form_data['km_user_city_prov'],
  $form_data['km_user_postcode'],
  $form_data['km_user_email'],
  $form_data['km_user_website'],
  $form_data['km_user_telephone'],
  $form_data['km_user_mobile'],
  $form_data['km_user_fiscalcode'],
  $form_data['km_user_document'],
  $form_data['km_user_document_number'],
  $form_data['km_user_document_exp'],
  $form_data['km_user_birth_place'],
  $form_data['km_user_birth_date'],
  $km_user_id
);

mysqli_stmt_execute($stmt);
20
задан Ikke 16 December 2011 в 16:15
поделиться

10 ответов

Я не уверен, что Мерзавец предназначен, чтобы использоваться этот путь.

Сначала быстрое совет Linus , всегда "красочный" и информативный ;)

Мерзавец очень существенно состояние проекта дорожек, не состояние файла. Что означает, что Вы очень НЕ можете попытаться "объединить файл". Это - бессмысленная операция в мерзавце, и на самом деле, любой SCM, который позволяет его в значительной степени, обречен быть общей частью sh т ().

(*) И я не говорю, что просто, потому что мерзавец не делает этого. Это намного более фундаментально, чем это. После того как Вы начинаете делать ветвление на файл и слияние, Вы в основном завинтили себя, и Вы никогда не будете мочь работать над проектом как "целый проект" больше - у Вас больше нет четко определенной истории, которая на самом деле является историей целого проекта.

<час>

Там.

Тем не менее Вы могли:

  • управляют теми, которые конфигурация/документ регистрирует отдельного мерзавца подпроекты (примечание: использование подмодулей было обсуждено здесь )
  • , или запишите частичное слияние (использующий "наш" стратегия файлов, которые мы не хотим объединять), затем - исправляют его.
<час>

Другие решения в этом потоке включают работу над "определенным для сервера" ответвлением по Вашему серверу развертывания

Development        Deployment

#origin/master:
x--x               $ git clone

                   # master
                   x--x

                   $ git checkout -b deployment origin/master

                   x--x
                       \ 
                        -- #deployment

                   $ .... #makes changes for config files
                          #or other specific deployment files

                   x--x
                       \
                        --d1--d2 # no need to push that branch ever.

#new developments
x--x--x--x

                   $ git pull --rebase #pull origin/master and 
                                       #replay current branch on top of it
                   x--x--x--x
                             \
                              --d1'--d2' #SHA1 rewritten in deployment branch
                                         #not important since this branch 
                                         #is not pushed (published)
11
ответ дан 30 November 2019 в 00:40
поделиться

Я делаю некоторые глупые приемы как:

  • приложение читало, файл config
  • Добавляют config.development и config.production, но не config в репозиторий
  • Имеют Ваш развертываться, сценарий не только клонируют репозиторий, но также и затем cp config.production config

, который имеет какой-либо смысл?

Это работает хорошо на меня.

4
ответ дан 30 November 2019 в 00:40
поделиться

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

3
ответ дан 30 November 2019 в 00:40
поделиться

Если Вы хотите сохранить свою историю хорошей, можно сохранить файлы развертывания в некоторых фиксациях сверх чистого ответвления. Затем когда пора развернуть новую версию, Вы проверяете ответвление развертывания и 'ведущее устройство перебазы мерзавцев', поместить те фиксации сверх исходного ответвления.

Тот путь, можно также внести легкие изменения в конфигурационные файлы и изменить главную фиксацию с 'фиксацией мерзавца - исправление'.

2
ответ дан 30 November 2019 в 00:40
поделиться

Я упомянул более ранние файлы исправления. Я ушел это теперь и вместо этого поддерживаю ответвления развертывания.

т.е., я отклоняюсь ведущее устройство с новым ответвлением, названным 'развернутым ведущими устройствами', и вношу изменения на том ответвлении, что я должен быть только в тестовой версии на сервере сборки (т.е. добавление предупреждения, что это не активная версия и другой сервер дб в web.config).

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

То же идет для подсказки обеспечения качества, которое имеет ответвление, 'развернутое на обеспечении качества'

, я использую - на флаг, чтобы удостовериться, переписывается ли целое ответвление тогда, патч не берет все старые фиксации с ним.

Так на сервере сборки быстродействующая сборка смотрит что-то как

git reset --hard
git clean -xfd
git checkout -f qa-deployed
git rebase --onto qa HEAD^ qa-deployed
build-script
1
ответ дан 30 November 2019 в 00:40
поделиться

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

0
ответ дан 30 November 2019 в 00:40
поделиться

Это работает для меня, и я вношу только незначительные изменения конфигурации для развертывания (3 строки в файлах конфигурации).

  1. Клонируйте свой репозиторий из GitHub или где бы вы его ни хранили. Туда, где вы хотите выполнить развертывание.

  2. Запустите git checkout -b deployment origin / master .

  3. Внесите свои изменения (отправьте их, если хотите).

  4. Каждый раз, когда ваш мастер (или любая другая ветка вы выполнили развертывание) есть изменения, которые вы хотите развернуть, просто git pull --rebase .

Это простое решение, и оно, безусловно, работает для меня, я не могу говорить с ним или нет это делает его "ши * том", как предлагают другие, но, безусловно, очень полезно для наших целей.

5
ответ дан 30 November 2019 в 00:40
поделиться

У меня была аналогичная проблема, и я создал крошечный проект под названием config-magic, чтобы помочь с этим.

Config-magic позволяет вам создавать файлы конфигурации шаблонов, а затем профили данных для каждого из следующих этапов: dev / staging / production. Затем вы запускаете «cfg dev» для создания файлов конфигурации «dev», «cfg staging» для создания промежуточной конфигурации и т. Д.

Затем я соединяю это со сценариями, так что при развертывании в промежуточном режиме я локально запустите "cfg staging", затем scp по всем файлам конфигурации после обновления кодовой базы с git.

"Фактические" файлы конфигурации должны игнорироваться git. До сих пор это работало у меня очень хорошо

https: // github. com / apinstein / config-magic / tree

1
ответ дан 30 November 2019 в 00:40
поделиться

Я думал обо всех этих решениях для моей ситуации, но ни одно из них, похоже, не применимо. Я редактирую как на моем рабочем сервере, так и на сервере разработки. Rebase работает хорошо, если вам не нужно повторно публиковать эту ветку, но я вношу изменения в свою ветку развертывания и публикую их обратно в основной репозиторий. Подмодуль работает только в том случае, если ваши файлы находятся в отдельном подкаталоге, мои файлы конфигурации находятся в нескольких местах. Наш метод слияния не будет работать так хорошо, потому что мне нужно сначала вытащить эту ветку, а затем большую ветку. Возможно, это сработало бы, если бы все еще было их объединение, и я мог бы при необходимости вставить правильную ветку конфигурации. На данный момент работает .gitignore, и я просто вручную загружаю файлы.

Проведя дополнительные исследования, я нашел свое решение - не иметь репозитория git на действующем сайте, а использовать промежуточный сайт для переноса последних изменений в свою ветку. с промежуточными / живыми файлами конфигурации. а затем развернуть с помощью архива git и распаковать файлы на мой действующий сайт.

1
ответ дан 30 November 2019 в 00:40
поделиться

вишнёвый выбор, похоже, подходит для этого (за счёт небольшого загрязнения логов).

git-тестирование -b вносить изменения и принимать обязательства мастер проверки git-технологий git-кассация -b развёртывание вносить изменения и принимать обязательства мастер проверки git

делает всё под мастером и git-cherry-pick тестирование или git-cherry-pick развертывание для применения различий, необходимых для перехода от текущей системы к тестовой или установочной версии

.
1
ответ дан 30 November 2019 в 00:40
поделиться
Другие вопросы по тегам:

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