Как мне улучшить и масштабировать рабочий процесс разработки приложений?

#python #git #iis #workflow #windows-server-2012-r2

#python #git #iis #рабочий процесс #windows-server-2012-r2

Вопрос:

У меня есть веб-приложение на Python, созданное с помощью Django. Он обслуживается в IIS на Windows Server 2012. Этот сервер является удаленным сервером, к которому у меня есть доступ. Мой текущий процесс разработки выглядит как одна из этих двух вещей (в зависимости от дня):

  • Редактируйте код Python напрямую на удаленном сервере и надейтесь, что изменения ничего не нарушат (а если нарушат, быстро попытайтесь их исправить)
  • Скопируйте все веб-приложение на мой локальный компьютер, внесите в него изменения и заставьте его работать, затем скопируйте фрагменты кода, которые я изменил, в серверную версию

Очевидно, что это не идеальные способы разработки и развертывания приложения. Какие конкретные шаги я могу предпринять, чтобы сделать это лучше, гибче и масштабируемее? Это то, к чему я пришел на данный момент:

  • Мне нужно начать использовать git, и я могу установить его как на локальном, так и на удаленном компьютерах
  • Однако я не могу связаться с удаленным сервером через SSH
  • Я также не думаю, что смогу взаимодействовать с удаленным сервером по протоколу HTTPS, потому что единственным жизнеспособным веб-сервером git для IIS является Bonobo, и он, похоже, не активен / полностью поддерживается. Для других автономных опций (например, gitea), похоже, требуются открытые порты, такие как 80 и 443…который необходим сайту IIS.
  • Я мог бы (маловероятно, но потенциально) использовать GitLab для ручной доработки кода, но он не будет размещен на том же удаленном сервере (на котором должно происходить развертывание)

Каковы основные варианты, позволяющие сделать этот рабочий процесс более терпимым и стабильным?

Комментарии:

1. Почему вы не можете использовать ssh?

2. не разрешено администраторами

3. Запрет SSH звучит так, будто администраторы не знают, что это такое? Может быть, вы можете использовать что-то вроде rsync?

4. но он все еще использует rsh или ssh, верно? согласованный с ними, не обязательно понимающий это