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

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

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

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

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

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


person Steerpike    schedule 27.04.2010    source источник


Ответы (4)


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

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

person Brian ONeil    schedule 01.05.2010
comment
Ключевым моментом здесь является общее место. Какой бы метод вы ни выбрали (вики, средства отслеживания ошибок, документ Word и т. Д.), Убедитесь, что это ЕДИНСТВЕННОЕ место, где людям нужно искать эту информацию. - person Ipsquiggle; 03.05.2010

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

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

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

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

Редактировать:

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

person Ipsquiggle    schedule 01.05.2010

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

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

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

person ndp    schedule 06.05.2010

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

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

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

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

person Chris Thornton    schedule 05.05.2010