Рабочий процесс фронтального разработчика ASP.NET Core с VSCode и VS 2019

Question

Я не делал никаких cshtml фронт-эндов разработок в течение нескольких лет.

Каков нынешний общепринятый способ работы фронтенд-разработчиков ASP.NET Core с различными инструментами в Windows?

Под этим я подразумеваю способ сборки JS-интерфейса и проекта (-ов) .NET также для быстрой сборки и работы в браузере и коде.

Я думаю так.

• Сегодня у нас гораздо лучшая история командной строки dotnet.
• Некоторым людям нравится VS Code.
• Некоторые люди предпочитают VS 2019, а некоторые любят и то, и другое.
• Нам иногда нужно работать над аспектами пользовательского интерфейса.
• Но нам также нужно подключить отладчик и иногда отлаживать логику сервера.
• Сервер сборки не должен иметь проблем, быть простым и полагаться главным образом на логику сборки, хранящуюся в репозитории.
• Инструменты и запуск всего процесса сборки и обслуживания должны быть понятными и знакомыми.
• Должно быть довольно просто начать работу после того, как нуб команды клонирует репо.

Первоначально я думал, что нужно настроить NPM, а затем использовать что-то вроде Gulp, чтобы запустить все, включая запуск dotnet run.

Затем при работе в отладчике Visual Studio 2019, используйте Task Runner Explorer, чтобы запустить Gulp, но пропустите часть dotnet run.

(жаль, что нет командной строки для запуска VS (код или 2019) и присоединения отладчика)

Теперь я ожидаю получить «в первую очередь основанное на мнении» ТАКОЕ избиение, но есть общие тенденции и идеи, которые входят в разработку всех этих инструментов для того, как они все могут играть в мяч вместе и как выглядит история разработчиков.

Answer 1

Вы в значительной степени уже описали процесс. Однако я добавлю несколько вещей:

1. Вам не нужен бит dotnet run. Visual Studio и VS Code способны отлаживать напрямую.

2. Вы можете назначить задачи gulp для создания задач в Task Runner Explorer, так что вам даже не придется думать о запуске их напрямую. Я не уверен в этом аспекте VS Code, но я уверен, что, возможно, есть какое-то расширение для его обработки, если оно еще не встроено.

3. Если вы хотите по-настоящему простоту разработки, лучшее, что вы можете сделать, это использовать Docker. Просто добавьте Dockerfile к каждому фактически запущенному проекту (т.е. не к библиотеке классов) и настройте шаги для его сборки и запуска. В Visual Studio вы можете щелкнуть правой кнопкой мыши по проекту и выбрать «Добавить»> «Поддержка Docker», и он фактически сгенерирует готовый файл Dockerfile, хотя вам может потребоваться добавить один или два шага для обработки этапов сборки на стороне клиента. В любом случае, это становится по-настоящему «нажми и беги», не о чем беспокоиться. Эта история становится еще лучше, когда вы используете docker-compose, поскольку Visual Studio и VS Code могут раскручивать весь стек приложений одновременно, включая внешние зависимости, такие как база данных, экземпляр Redis и т. Д. Если вы не использовали Docker раньше, начни сейчас. Это абсолютно революционно для развития.

Одна заметка для CI / CD, насколько это возможно, вы должны добавить файл YAML для описания вашего конвейера CI / CD. В зависимости от фактического поставщика, который вы используете для сборки / выпуска, могут быть некоторые различия, поэтому обратитесь к соответствующей документации. (Например, в настоящий момент Azure DevOps не поддерживает описание конвейеров выпуска в yaml, хотя вы все равно можете выполнять сборку таким образом.) В любом случае это позволяет вам сконфигурировать все это в коде и передать его в управление исходным кодом. .

Вы можете рассмотреть то же самое для вашей инфраструктуры. Azure имеет шаблоны ARM, AWS имеет CloudFormation, GCP имеет Deployment Manager. Есть также сторонние инструменты, такие как Terraform или Ansible. Все они в той или иной форме (обычно в формате JSON или YAML) позволяют вам определить все характеристики инфраструктуры, в которой вы собираетесь развернуть, и передать ее в систему контроля версий. Это делает развертывание и такие вещи, как создание новых сред максимально быстрым.