Saboteur

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

from random import randint
comparison = 0
transfer = 0

arr = [randint(1, 100) for _ in range(10)]

def bubble_sort():
    global comparison
    global transfer
    for i in range(9):
        for j in range(9 - i):
            comparison += 1
            if arr[j] > arr[j + 1]:
                arr[j], arr[j + 1] = arr[j + 1], arr[j]
                transfer += 1

print('original array\n', *arr)
bubble_sort()
print('bubble sort\n', *arr)
print('comparisons: ', comparison)
print('transfers: ',transfer)

Можно написать такое на коленке скрипт, который периодически бегает по энвайрнментам, собирает версии и выводит в удобном виде.
Без сильного заморачивания, я бы добавил в каждое приложение ендпоинт, который возвращает версию, и просто собирал бы это каким-нить js или даже shell скриптом.
Пушить изменения в JIRA уже можно собрав инфу.

Ну а в богатых конторах, для деплоя используются тулзы, которые могут показывать что где. Какой-нить IBM uDeploy (хотя это не лучший вариант).

Это делается правами доступа к папкам и запуске вашего процесса от имени юзера, у которого есть доступ.

1. Договор - полюбому. Чтобы можно было прижучить.
В нормальных команиях также секьюрити проводят регулярные таунхолы, особенно для новичков, где рассказывают о безопасности. И приводят пару примеров, как кто-то расшарил кусочек кода, как его засудили на много денег и добавили в черные списки всех компаний.
Это для тех, кто по глупости может.

2. Делите исходники на части. Автоматизируйте деплой так, чтобы разработчик это руками не делал и никуда не лазил - сделал коммит - CI сервер автоматом закачал все нужное из разных репозиториев и задеплоил. Надо нескольким разработчикам - сделайте несколько тестовых окружений, чтобы разработчик мог зайти в Jenkins или Teamcity, нажал одну кнопку и выбрал куда ему деплоить. Но своих логинов парлей у него не было.

3. В любом случае, если кто-то захочет стырить код - он это сделает. Сделать так, чтобы не было доступа для тех, кому этот доступ нужен - это только навредит проекту.
Поэтому пусть у вас работает нормальный HR.
Пусть тимлиды присматриваются к людям, не доводят до конфликтов.
Не дают доступ ко всему до прохождения испытательного срока.

И это все равно не гарантия. Смиритесь =)

Читаете базовое понятие о том как работает сеть.
Смотрите способы передачи информации по сети - в принципе сейчас в основном две - http запросы или socket.
Читаете как пользоваться библиотеками для вашего языка программирования.
Пишете.

P.S. Вопрос ваш слишком общий. Нужно конкретизировать.

маст хев:

Понимание принципа работы ssh ключей, чтобы уметь настроить себе доступ на линукс машину или в гит (bitbucket/github/etc)

Базовое понимание git и то, что висит поверх него (github, bitbucket, etc) чтобы не путаться в пулл реквестах, понимать зачем они и как организована у вас работа - неймконвенш для веток, как ревью делается

Если пишете под докер, то Dockerfile - это в основном ответственность разработчика. Где его запускать - уже второй вопрос.

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

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

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