Стратегия автоматического развертывания TFS Intranet

Question

Я ввел разветвление/слияние с моей командой и рассказал раньше о том, как было бы здорово автоматически создавать и разворачивать код, проверенный в ветвях промежуточного/основного, но я младший разработчик, а не очень ops-y.

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

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

т.е.

1) I check in some code to stage 
***Automatically*** 
2) Code builds 
3) Build completes, Unit tests run and they complete 
4) Code is packaged into a .zip 
5) .Zip is deployed across the three load balancing servers (all with the same file path). 
*** 

Может быть, стоит отметить, в настоящее время мы имеем наш сервер TFS работает Visual Studio, так что код построен на том же сервере, все это хранится, но это не сервер бежим живой код с.

Любая помощь или учебные пособия, специфичные для моей установки, были бы НАСТОЯТЕЛЬНО оценены, я действительно хочу, чтобы эти отделы выпускали стратегии!

Answer 1

Я собираюсь рассмотреть только аспекты развертывания. Есть много различных способов, которыми это может быть обработаны, например:

1. Настройка шаблона сборки
2. Написание кода пользовательского .Net и вставить его в шаблон сборки (который также будет включать в себя настройки шаблона)
3. Создание пакетного или Powershell скрипт установки для запуска после сборки завершает
4. Использование отдельного инструмента, такого как OctoDeploy или менеджера выпуска для обработки развертываний

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

Есть 3 основных вещей, которые необходимо сделать, то:

1. все должно быть стандартизированы. Если вы не можете стандартизировать что-то, тогда стандартизируйте способ, которым он нестандартен (например: у вас есть массовый список серверов, которые вам нужно развернуть, и вам нужно выяснить, какие из них следует развернуть на основе их имени, что может быть что угодно. В этом случае необходимо установить правило, что всем серверам QA необходимо иметь QA в их имени, серверам Accept Acceptance нужны UAT, Production PROD и т. д.).
2. Выясните, как вы собираетесь связываться из сборки с развертыванием, какие сборки будут развернуты, на какие серверы и где код будет снят с
3. Вам необходимо задокументировать каждое руководство шаг и каждое исключение из этих шагов, и каждое исключение из этих исключений.

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

Быстрое резюме того, как я сделал это в моей нынешней работе (где с помощью средства развертывания третьей стороной был не вариант):

1. создал инструмент, используя .NET WinForms, чтобы позволить нам «вручную» запускает автоматические сборки (мы используем интерфейс для определения входных параметров, а пользовательские классы под капотом выполняют весь тяжелый подъем. Эти пользовательские классы находятся в отдельном проекте, который строится на собственной DLL. Это также позволяет нам тестовые настройки и изменения процесса в тестовой среде, прежде чем мы откатимся от него на нашем сервере сборки производства)
2. Настройте XML-файл для каждого набора окружения (QA, UAT, Prod и т. д.). который содержит все серверы, которые необходимо развернуть в этой среде, включая пути назначения, запланированные задачи и службы Windows.
3. Настроить шаблон сборки TFS и включить пользовательские классы, созданные для настраиваемого инструмента, который будет читать XML файл и итерацию через каждую запись на сервере для выполнения развертываний

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