NTLM Завершается в Git/libcurl: Командам Azure DevOps Server Нужен Реальный План Миграции

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

Предстоящее удаление NTLM в libcurl — одно из тех изменений, которые выглядят техническими, но на самом деле являются организационными. Если ваш путь Git over HTTPS к Azure DevOps Server все еще зависит от NTLM, ваша проблема не в инструментах, а в долге по идентификации.

Оригинальный источник: https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/

Microsoft права, настаивая на этом. NTLM имеет известные криптографические слабости и не должен быть современным корпоративным стандартом по умолчанию. Опасная часть в том, что многие среды считают, что используют Kerberos, когда на самом деле они выживают за счет тихого отката SPNEGO к NTLM. Эта иллюзия исчезнет в сентябре 2026 года.

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

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

Во-первых, проверьте текущее поведение аутентификации сейчас. Запустите trace-проверки и валидацию кэша билетов в реальных контекстах разработчиков и билд-агентов, включая пути вне домена и удаленных сетей. Во-вторых, исправьте Kerberos end-to-end: SPN, DNS-алиасы, настройки балансировщика нагрузки, делегирование и доступность контроллера домена. В-третьих, идентифицируйте сценарии без присоединения к домену или рабочие группы на раннем этапе и спроектируйте SSH-путь там, где Kerberos не может быть надежным.

Вам также нужна четкость в отношении ответственности. Команды безопасности должны определить базовые политики, но платформенная инженерия должна владеть готовностью реализации. Это не может быть побочной задачей для отдельных администраторов репозиториев. Требуются скоординированные изменения в IIS, AD, на сетевом периметре, CI-агентах и руководствах для рабочих станций разработчиков.

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

Плюс реален. Чистый переход на Kerberos или SSH не только избегает поломок, но и уменьшает поверхность атаки и приводит управление идентификацией в соответствие с современными ожиданиями комплаенса. Команды, которые начнут этот переход сейчас, будут рассматривать сентябрь как рядовое событие. Команды, которые будут ждать, будут отлаживать ошибки аутентификации под давлением релиза.

Это не предупреждение для архивации. Это дедлайн для исполнения.

Ревью pull request прямо внутри Visual Studio — это именно тот тип снижения трения, который мне нравится

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

Эта статья переведена автоматически. Оригинал можно прочитать здесь.

Браузер слишком долго забирал на себя слишком большую часть workflow code review.

Поэтому я очень рад видеть, что Visual Studio двигается дальше в сторону end-to-end review pull request прямо внутри IDE.

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

Главная ценность проста: меньше переключения контекста

Когда ваш review loop живёт частично в IDE, а частично в браузере, трение накапливается:

открыть PR в другом месте
посмотреть изменения в одном инструменте
вернуться к solution для более глубокого изучения
снова переключиться, чтобы оставить комментарий или одобрить

Это не катастрофа. Это просто неэффективно.

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

Опция “review без checkout” особенно хороша

Одна вещь, которая мне особенно нравится, — возможность делать review без checkout ветки PR.

Это может звучать мелко, но отлично подходит для:

быстрых проходов review
feedback-запросов, возникающих во время прерываний
сохранения текущей ветки и локального состояния без изменений

Это именно тот тип гибкости, который нужен хорошим code review tools.

Моё мнение

Это не революционная функция.

Это лучше: это практичная функция.

Для команд, которые проводят большую часть дня в Visual Studio, более тесная поддержка PR review означает меньше разрывов workflow и более плавный путь от инспекции к действию.

На мой взгляд, это достойное улучшение.

Оригинальная публикация: Ревью pull request без выхода из Visual Studio

Git | The .NET Blog

NTLM Завершается в Git/libcurl: Командам Azure DevOps Server Нужен Реальный План Миграции

Ревью pull request прямо внутри Visual Studio — это именно тот тип снижения трения, который мне нравится

Главная ценность проста: меньше переключения контекста

Опция “review без checkout” особенно хороша

Моё мнение