Как отследить в проекте посторонние причуды - PullRequest
5 голосов
/ 27 апреля 2010

Возможно, что ответом на этот вопрос может быть просто стандартное программное обеспечение для отслеживания ошибок, такое как jira или fogbugz, но я надеюсь, что кто-то там знает лучшую систему для того, что я описываю.

Мой самый текущий проект требует лот изворотливости настройки, чтобы попасть в положение, где я действительно могу начать раздел кодирования. Например:

  • Серия запутанных внутренних команд компании, прежде чем я смогу завести SSH.
  • Убедитесь, что для всех сторонних классов, выполняющих внешние вызовы, настроены параметры внутреннего прокси-сервера компании, а также убедитесь, что эти параметры не будут установлены при установке в производственной среде
  • Перед установкой пакетов Pearl убедитесь, что прокси-сервер установлен.
  • Другие подобные вещи, в основном связанные с внутренней ИТ-безопасностью и заставляющие работать с модулями и пакетами.

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

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

Ответы [ 4 ]

7 голосов
/ 01 мая 2010

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

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

6 голосов
/ 01 мая 2010

Инкапсулируйте каждую из этих задач в какой-либо скрипт (bash, python, applecript, autohotkey, все, что подходит для задачи).

Затем создайте различные мета-скрипты для их вызова. Например. "Set_up_everything.bash".

По сути: вместо того, чтобы тратить время на написание всего, что вам нужно сделать, потратьте время на написание сценария / программы, которая делает все, что вам нужно сделать.

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

Edit:

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

2 голосов
/ 06 мая 2010

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

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

Пару лет назад это звучало бы как сумасшедший разговор.Но в наши дни каждый наш проект может быть проверен и запущен без проблем.(Побочным эффектом является то, что непрерывная интеграция тривиальна в настройке.) Даже возможно иметь одну кнопку, которая обеспечивает сервер от AWS, устанавливает и ОС, все необходимые инструменты, извлекает наше приложение из github и развертывает его.Просто сделал это на днях!Имей веру!

1 голос
/ 05 мая 2010

План A: Устранить зависимость от внешних систем, настроив надлежащую среду тестирования, которой вы можете управлять. Это может включать настройку фиктивных баз данных, фиктивных серверов SOAP (SoapUI Mockservices) и т. Д. Вам следует попытаться достичь точки, в которой вы можете рассматривать все внешние элементы как черные ящики, которыми вы можете управлять с помощью этих сервисов mock / dummy / stub. , с минимальной перенастройкой (например, замена файлов .ini).
В идеале это должно быть «устройство» в виде среды размещения, например zip-файл каталога, содержащий все необходимые базы данных, исполняемые файлы и т. Д. Возможно на флешке.

Нет, я не живу и не работаю в такой утопической среде! Но это, как я себе представляю, как это должно быть сделано.

План Б: Предполагая, что вы не можете выполнить вышеизложенное, вы застряли в тестировании на внешние устройства, такие как «живые» сети и серверы. т. е. ваш запрос к базе данных выполняется на чужом тестовом сервере баз данных, и вы надеетесь, что он содержит те же данные, что и в прошлый раз, когда вы тестировали. Таким образом, вам нужно иметь минимальный набор тестов, который можно запустить, чтобы убедиться, что внешний вид такой же, как и в прошлый раз. Может быть вчера, в прошлом месяце, в прошлом году. Предположим, вам нужно получить записи сотрудников из базы данных HR-тестов. Итак, есть тестовое приложение, которое гарантирует, что оно может подключаться, входить в систему, запрашивать записи и сравнивать набор результатов с набором результатов «последний известный результат». Теперь ты в порядке. Если вы не добились этого, работайте через него (исправьте свой логин, конечные точки, имена хостов, прокси, настройте учетную запись, обновите драйверы и т. Д.) ДО того, как вы будете беспокоиться о кодировании / тестировании / демонстрации остальной части система. Это сэкономит много времени и предотвратит истощение новых разработчиков, которые сдаются и выходят через 3 дня, потому что nothign работает.

Обновление: и что бы вы ни делали, включите его в систему контроля версий, чтобы вы могли вернуться, сравнить и т. Д.

...