Сергей Горностаев

Вопрос похоже поставлен некорректно.
На гитлабе хранятся только исходники. Там не надо выполнять миграции.
Создать миграцию - это сделать файл миграции, который будет преобразовывать БД.
Выполнить миграцию - это применить логику этого файла к конкретной БД.
Выполнять миграцию вы можете на любой машине, но подключаться при этом должны к конкретной БД на которой хотите применить эту миграцию.
Обычно к какой БД подключаться указывается в настройках.
Если у вас есть продакшн-сервер, на котором запущен проект, то миграции делаются (выполняются, применяются к БД продакта) при деплое (релизе) очередной ревизии. Обычно это происходит после успешного слияния текущей рабочей ветки в релизную.
Есть такой механизм, который называется CI\CD. Он отвечает за обнаружение нового коммита в релизной ветке, сборку продукта (докер-образов, например) и выкатку (остановку старой и запуск на проде новой версии продукта). При этом настроен автоматический запуск миграций.

Связь осуществляется через сетевое соединение, а именно через сокеты и кучу разных протоколов поверх типа HTTP/WS и прочего. На стороне сервера реализуете выбранный вами протокол в виде сервиса API, который слушает сокет, а в десктопном приложении подключаетесь к серверу и взаимодействуете с API вашего сервиса.

Вернуться к изучению основ, разобраться как работают изменяемые объекты, что такое передача по ссылке и по значению, формулировать какую вообще задачу вы решаете подобным кодом.

Сейчас вы ссылаетесь на один и тот же объект 3 раза, вместо создания нового объекта.
Исправляется созданием плоской копии списка.

lst = []
l = []
for i in range(3):
    l.append(i)
    lst.append(l[:])
print(lst)

Поясню ответ выше: насколько я знаю, графические интерфейсы строго однопоточны. Как минимум под Windows это так, а потому ни один графический фреймворк не поддерживает обращение к окнам и их элементам из других потоков.
Как следствие, если ты хочешь организовать фоновый поток с "обратной связью" в GUI, обычно требуется использовать очередь, например, queue.Queue. В эту очередь фоновый поток должен класть сообщения, объясняющие, что надо сделать - например, сведения о прогрессе операции, или команды на смену состояния, или ещё что. Это зависит от твоей задачи.
Тогда основной поток программы, который и отвечает за GUI, должен использовать средства фреймворка для периодической проверки очереди на предмет сообщений. Например, в обычном tkinter это будет реализовано через метод after().
Если в очереди есть сообщения, основной поток читает их и выполняет соответствующие действия - например, меняет положение прогресс-бара, включает/выключает кнопки, и т.д.
Если фоновый (рабочий) поток живёт долго, то может иметь смысл организовать вторую очередь для передачи команд из GUI-потока в рабочий. Идея та же самая: рабочий поток ждёт появления команды в своей входной очереди, и выполняет её, а потом сбрасывает уведомления в исходящую очередь.

нанимается проджект менеджер, который рулит людями
выбирается тимлид, который рулит командой.
проджект и тимлид делят проект на задачи - проджект с точки зрения бизнеса, тим лид с точки зрения технической реализации
потом задачи выдаются разработчиками.
Технически в этом помогает какой-то трекер, типа JIRA и система контроля версий и система ревью. Типа битбакет, гитхаб, гит, и другие.
А так - слишком общий и нетехнический вопрос,

Задача не имеет решения.

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

А что помешает энтузиасту-фанату написать свой плеер с функцией сохранения? Опять же аудиопоток можно банально записать с аудиовыхода - без всяких аудиокабелей - просто включив воспроизведение в колонки и положив рядом телефон :) Да, качества не будет, но обычно когда задумываются о такой вот вещи - качество не нужно, обычно это аудиозаписи "волшебных курсов", там достаточно разборчивого текста.

При продолжительной работе

скорее всего это проблема про которую написано в оф доках https://docs.python.org/3/library/asyncio-task.htm...

Important Save a reference to the result of this function, to avoid a task disappearing mid-execution. The event loop only keeps weak references to tasks. A task that isn’t referenced elsewhere may get garbage collected at any time, even before it’s done. For reliable “fire-and-forget” background tasks, gather them in a collection:

долбить API с меньшей частотой, а еще лучше, выяснить какие у них лимиты и начать их соблюдать