Как отслеживать в проектах посторонние причуды


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

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

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

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

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

4 ответа:

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

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

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

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

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

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

Правка:

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

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

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

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

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

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

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

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