Настройка среды Git.Нужен совет - PullRequest
5 голосов
/ 26 января 2012

Справочная информация:

  • В настоящее время мы 3 веб-программиста (хорошие, настоящие друзья, никаких проблем с недоверием).
  • Каждый программист SSH на отдельный сервер Linux, где находится код, под своим собственным именем пользователя с полномочиями sudo.
  • Мы все используем работу над разными файлами одновременно. Мы задаем вопрос "Вы в файле __?" иногда. Мы используем Vim, поэтому мы знаем, открыт файл или нет.
  • Наш код разработки (пока не производится) находится в / var / www /
  • Наше удаленное хранилище размещено на bitbucket.
  • Я * очень * новичок в Git. Раньше я использовал Subversion, но в основном мне давали ложные инструкции, и мне точно сказали, что печатать, чтобы синхронизировать коды и фиксировать.
  • Я прочитал около половины Pro Git Скотта Чакона, и это большая часть моих знаний о Git.
  • Если это имеет значение, мы запускаем Ubuntu 11.04, Apache 2.2.17 и Git 1.7.4.1.

Итак, Ян Худек дал мне несколько советов в предыдущем вопросе. Он сказал мне, что хорошей практикой является следующее:

  • Каждый разработчик имеет собственный репозиторий на своем локальном компьютере.
  • Пусть / var / www / будет репо на сервере. Установите для папки .git разрешение 770.

Это означает, что на компьютере каждого разработчика должен быть свой собственный стек LAMP (или, по крайней мере, установлены Apache, PHP, MySQL и Python).

Коды в основном представляют собой файлы JavaScript и PHP, поэтому клонировать их не составляет особого труда. Однако как мы можем локально управлять базой данных?

В этом случае у нас всего две таблицы, и будет легко воссоздать всю базу данных локально (по крайней мере, для тестирования). Но в будущем, когда база данных станет слишком большой, мы должны просто удаленно войти в базу данных MySQL на сервере или у нас будет просто «образец» данных для целей разработки и тестирования?

Ответы [ 3 ]

4 голосов
/ 26 января 2012

То, что вы делаете, - это переход от «все работают вместе в одной среде» к «у каждого своя среда разработки».Основное преимущество заключается в том, что все не будут наступать друг другу на ноги.

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

Главный недостаток, как вы заметили, заключается в том, чтонастройка среды сложнее.В частности, убедитесь, что база данных работает.

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

Во-вторых, вам следует имеет схему , а не только то, что находится в базе данных.Он должен находиться в файле с управлением версиями.

В-третьих, установка новой базы данных должна выполняться автоматически.Это позволяет разработчикам без проблем создавать чистую базу данных.

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

У вас есть несколько способов сделать это.

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

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

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

Наконец, вы можете создать набор библиотек, которые генерируют для вас полуслучайные данные.Я называю это «Техникой симов» после видеоигры, в которой вы создаете поддельные семьи, мучаете их, а затем выбрасываете их.Например, допустим, у вас есть объект User, которому нужно имя, возраст, объект Payment и объект Session.Чтобы протестировать пользователя, вам могут потребоваться пользователи с разными именами, возрастами, способностью платить и статусом входа.Чтобы контролировать все, что вам нужно, генерировать тестовые данные для имен, возрастов, платежей и сессий.Итак, вы пишете функцию для генерации имен и одну для генерации возрастов.Это может быть так же просто, как случайный выбор из списка.Затем вы пишете один, чтобы сделать вас объектом платежа, а другой - объектом сеанса.По умолчанию все атрибуты будут случайными, но действительными ... если не указано иное.Например ...

# Generate a random login session, but guarantee that it's logged in.
session = Session.sim( logged_in = true )

Тогда вы можете использовать это, чтобы собрать интересного пользователя.

# A user who is logged in but has an invalid Visa card
# Their name and age will be random but valid
user = User.sim(
    session = Session.sim( logged_in = true ),
    payment = Payment.sim( invalid = true, type = "Visa" ),
);

В этом есть все преимущества тестовых приспособлений, но, поскольку некоторые данные непредсказуемы, у них есть некоторые преимущества реальных данных. Добавление «интересных» данных в функции по умолчанию для sim и rand будет иметь широкий спектр последствий. Например, добавление имени Unicode к random_name, вероятно, обнаружит все виды интересных ошибок! К сожалению, это дорого и требует много времени.

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

1 голос
/ 26 января 2012

Несколько вариантов, в порядке возрастания сложности:

  • Вы все подключаетесь к живой главной базе данных, права на чтение / запись.Это рискованно, но я думаю, вы уже делаете это.Убедитесь, что у вас есть резервные копии!
  • Используйте тестовые таблицы для заполнения локальной тестовой БД и просто используйте ее.Не уверен, какие инструменты существуют для этого в мире PHP.
  • Скопируйте (mysqldump) базу данных master и импортируйте ее в экземпляры MySQL на локальных машинах, а затем настройте среды разработки для подключения к локальному MySQL.При необходимости повторите дамп / импорт
  • Настройте одностороннюю репликацию с мастера на локальные экземпляры.

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

0 голосов
/ 26 января 2012
  1. Собственное репо не означает собственный промежуточный сервер (эта конфигурация почти не поддерживается и крайне плохо масштабируется для 10-20-100 разработчиков)
  2. Всегда лучше иметь как можно скорее (полу) автоматизированную систему сборки, которая преобразует исходные данные, хранящиеся в хранилище, в работающую систему (меньше ручной работы - меньше изменений, чтобы сделать ошибки без кода)) и (возможно) некоторый тип интеграции Continuos (тестируйте часто, быстро находите ошибки).Для системы сборки (часть БД) вам нужно только подготовить исходные данные (структуры таблиц, дампы данных) в виде (версий) текстов, которые

    • легко объединить между объединениями
    • обрабатывается, обрабатывается и преобразуется в конечный пригодный для использования объект по коду, а не вручную - без человеческих ошибок, без вмешательства операции
...