Статьи

3 простых правила для управления решениями

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

  1. Всегда используйте какой-либо источник контроля.

    Существует целый ряд решений по управлению исходным кодом, которые могут охватить практически любую ситуацию, связанную с разработкой, от одинокого хобби до огромных территориально распределенных команд. Именно то, что вы используете, должно зависеть от ваших требований и инфраструктуры. Но разработка без системы контроля версий безответственно для ваших клиентов, работодателей или только для вас. Вам даже не нужно заниматься управлением системой самостоятельно — размещенные решения SVN доступны за несколько долларов в месяц. А на нескольких сайтах предлагаются бесплатные общедоступные системы контроля для проектов с открытым исходным кодом.

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

  2. Если это неотъемлемая часть проекта, он находится в системе контроля версий.

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

    Один очень интересный вопрос касательно этого вопроса: «Следует ли включить в эту систему удаление базы данных?». Мой общий ответ — да, с пониманием, что это может быть логически невозможно из-за размера или чувствительности этих файлов. Если это не так, следует приложить все усилия для присоединения образца базы данных к решению с управлением исходным кодом, чтобы гарантировать, что разработчик имеет дело с единым магазином.

  3. Передача в нетронутую среду должна быть минимальной суетой.

    Сколько раз вы получали проект, который, даже если он строится с первой попытки, требует часов настройки и настройки файлов конфигурации, системных настроек и базы данных, чтобы он действительно работал? Этого никогда не должно случиться.

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

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

пнуть его на DotNetKicks.com