Saboteur

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

В глаза кидаются мелочи типа

В каждом сервисе подключен бутстрап конфиг, в котором подключены 4-5 конфигмапов дополнительно

А почему у вас несколько конфигмапов на одно приложение, а не один конфигмап?

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

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

По итогу можно провтыкать изменить на каком-то окружении параметр, и всё..окружения уже не одинаково настроены.

Делать статические параметры, и в конфигмапы выносить исключительно environment-related опции.

По вашему вопросу никто не скажет решения. Это нужно сесть и переделать.
У меня свыше 100 компонентов, десяток енвайрнментов. Конфигмап один на неймспейс, секрета два на неймспейс, в принципе достаточно.

В вашем случае было бы удобнее всего работать с докером.
При этом все тесты должны быть автоматическими и запускаться на localhost

Любым CI инструментом настраиваете триггер на коммит или пулл реквест, чтобы собрать проект, сбилдить докер образ, запустить его и внутри запустить автотесты.

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

Так вы вопрос сформулируйте, что именно не получается.
Если вопрос в автоматической установке приложения - ну любое приложение это в конечном счете просто файлики и, может быть, немного реестра.
Можно взять чистую виртуалку, включить регмон/файлмон и отследить что и куда поставит инсталлятор. Затем руками можно будет уже ставить без инсталлятора.

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

А в чем проблема сделать локальное окружение такое же как в тимсити?
Сохранить ту же структуру каталогов.
Все основные переменные хранить не в тимсити а прямо в коде, сделать несколько конфигурационных файлов/папок для разных енварйнментов, в том числе и local профайл
Даже пароли можно хранить в коде, если зашифровать и локально/в тимсити хранить только мастер ключ для нужного енварйнмента.

Либо да, разобраться с контейнерами, но не всегда это удобно

CI/CD это не организация команд, это организация процесса автоматической сборки/деплоймента/тестирования.

Для этого девопс/админ или шарящий в этой теме разработчик придумывают правила (branching name conventions, versioning, настраивает соответствующие инструменты и инфраструктуру (teamcity/jenkins/какой-нить bitbucket с пулл реквестами. Чтобы по коммиту собирался билд, проходили юнит тесты, результат деплоился в тестовый энвайрнмент, запускались автотесты, результат возвращался в пулл реквест и подтверждал действие.
Чтобы деплоймент на тестовый энвайрнмент делался одной кнопкой, чтобы деплой на прод делался одной кнопкой с предварительным подтверждением и аппрувалом также в цифровом виде.
Вот это все.

А команды - как угодно можно сделать.

Пути поправьте. В ваших кракозябрах про это и говорится:

проект "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\ArchitectureTools\Microsoft.VisualStudio.TeamArchitect.ModelingProject.targets" не обнаружен.
Проверьте путь в объявлении и наличие файла на диске.

error MSB4019: импортированный проект "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\DotNet\Microsoft.DotNet.Props" не обнаружен.
Проверьте путь в объявлении и наличие файла на диске.

Варианты могут быть такие:
а) На каждый коммит сразу идет сборка продукта и прогоняются интеграционные тесты.

Плюсы такие - на рабочем месте вам нужен только GIT и IDE, все компиляторы, окружение для запуска приложения - на нодах билдсервера. В результате вы можете кодить откуда угодно, и сразу проверять целостность сборки с каждым коммитом.

б) сборка может быть ночной. Например потому что билд идет 5 часов на толстом сервере, и на рабочей машине он будет идти 10-15 часов, а то и не идти вообще. Тогда конечно, желательно не ломать билд недоделанными коммитами. Но git же позволяет коммитить без пушей, либо пользоваться бренчами, и настраивать сборку не на просто коммит, а на мерж в девелоперский или мастер бренч.

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

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

Напишите свой велосипед вместо CI
Дженкинс легче просто дальше некуда, а с вашими требованиями, чтобы еще и бесплатно и маленькое и все работало - пишите просто свои скрипты.