SerzN1

вопросы у вас философские, на каждый можно отвести часы обсуждения

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

Упрощаю вопрос:
Я запланировал сделать это за две недели, но ошибся в оценке. Что делать?
Ответ на мой взгляд очевиден:
Извиниться, признать ошибку, сделать выводы. Все остальное (типа привлечение доп ресурсов, введение ночных смен и т.п.) это попытка прикрыть свою ошибку как менеджера за счет компании.

Сфорткали панораму, с помощью коптера нарпимер, и нарисовали на canvas на webgl. Используется вот это: https://krpano.com/docu/html5/

Так, мой комент с матом удалили. Напишу без мата (хотя это очень сложно) - много удаленки потому что битрикс очень плохая система и никто не хочет с ней работать кроме ушлых разрабов которые берут за это басновсловные деньги. А распространена она так, потому что продавая лицензии студии и частники получают партнерские отчисления. Втюхивают и подсаживают на этот ад, заламывая цены, если отказываются платить - бросают и привет мытарства по фрилансу. Одна и та же доработка например формы обратной связи обойдется на битриксе в два-три-двадцать раз дороже чем на условном вордпрессе. Бесплатных плагинов и готовых решений очень мало. Отвратительная документация, архитектура, комьюнити. Я 15 лет в веб-разработке и единственное что могу посоветовать - никогда не связывайтесь с этим ужасом если вы клиент и хотите себе сайт. А вот если вы разраб и хотите хорошо заработать на несчастных - то вперед, битрикс самое то.

function _send (s) {
	var input = document.getElementById("input");
	input.value=s;
	var evt = document.createEvent("HTMLEvents");
	evt.initEvent("input", false, true);
	input.dispatchEvent(evt);
	var t = document.querySelector('.well span')
	console.log("%s => %s", s, (t.textContent.search ("true") > -1) );
}

for(var code = 0; code < 1000; code++) {
  _send (String.fromCharCode(code));
}

Отфильтровать по условиям можно так:

var sell = [
    {"breed": "sosna", "size": "20x100x6000", "cost": 1500},
    {"breed": "sosna", "size": "30x100x6000", "cost": 2500},
    {"breed": "sosna", "size": "40x100x6000", "cost": 3500},
    {"breed": "sosna", "size": "20x100x6000", "cost": 4500},
    {"breed": "sosna", "size": "30x100x6000", "cost": 5500},
    {"breed": "sosna", "size": "40x100x6000", "cost": 6500},
];

var breed = ["sosna"];
var size = ["30x100x6000", "20x100x6000"];
var params = { breed, size };
var activeKeys = Object.keys(params).filter(function(key) {
  return params[key].length;
});   
  
var filtered = sell.filter(function(item) {
  return activeKeys.every(function(key) {
    return params[key].indexOf(item[key]) != -1;
  });
});

С использованием ES6:

const sell = [
    {"breed": "sosna", "size": "20x100x6000", "cost": 1500},
    {"breed": "sosna", "size": "30x100x6000", "cost": 2500},
    {"breed": "sosna", "size": "40x100x6000", "cost": 3500},
    {"breed": "sosna", "size": "20x100x6000", "cost": 4500},
    {"breed": "sosna", "size": "30x100x6000", "cost": 5500},
    {"breed": "sosna", "size": "40x100x6000", "cost": 6500},
];

const breed = ["sosna"];
const size = ["30x100x6000", "20x100x6000"];
const params = { breed, size };
const activeKeys = Object.keys(params).filter(key => params[key].length);
     
const filtered =
  sell.filter(item => activeKeys.every(key => params[key].includes(item[key])));

Найти минимум можно так:

var min = sell.reduce(function(acc, el) {
  return acc < el.cost ? acc : el.cost;
}, Infinity);

или:

var values = sell.map(function(el) {
  return el.cost;
});

var min = Math.min.apply(Math, values);

С использованием ES6:

const min = sell.reduce((acc, el) => acc < el.cost ? acc : el.cost, Infinity);

или:
const min = Math.min(...sell.map(el => el.cost));

Tour, wizard, steps, etc - это всё инструменты, частные варианты.

Этот процесс называется Onboarding.
Поэтому можно гуглить что-то из серии "web site onboarding best practice"

1. Отключить внешние раздражители - очень важно. Телевизор и подобное лучше вообще убрать подальше.
2. Научиться правильно отдыхать, в том числе - чтобы голова отдыхала. Закончили работу - переключайтесь на то, что происходит вокруг, общайтесь, забудьте вообще о работе. Можете 10 минут удерживать "пустоту" в голове, не думать ни о чем? Чтобы ни одна мысль не пролезла в голову? Дайте мозгу "проголодаться", сразу станет интереснее.
3. Ваша проблема - не только Ваша, с ней сталкиваются практически все так или иначе. Приходится учиться, находить свой ритм работы и отдыха. Допустим, отдыхаете каждые полчаса. Каждый раз, завершив какую-то подзадачу, ставите отметку "выполнено". В связи с этим - полезная техника: составляйте план из микрозадач и, по мере их выполнения, ставьте галочки напротив каждой выполненной задачи. Мелочь, а хорошо помогает в плане концентрации.
4. Одной из причин может быть то, что Вы ставите перед собой сразу много обязанностей, мозг воспринимает это как неподъемную задачу и блокирует ее выполнение. Разбивайте задачу на более мелкие и не обещайте себе выполнить непременно все. Отдыхайте, переключайтесь, развлекайтесь.
5. Не держите все в голове - записывайте. Разгружайте голову. Когда занимаетесь - ведите подробные конспекты. Это помогает структурировать информацию. На экзамене очень выручает - Вы вспоминаете не информацию из учебника, а то, что сами записали в конспект, как будто это Ваше творение. Вам остается только воссоздать свой конспект на листочке, что обычно происходит легко, как будто само собой.
6. Лучший отдых - это перемена занятий. Найдите противоположный вид деятельности, например, спорт, и работайте с реальной отдачей, до изнеможения. Уровень концентрации в вашей основной области повысится в разы.
Пробуйте, ищите, учитесь. Есть целое направление - brain fitness, посмотрите, может, найдете что-то полезное и для себя.

Мозг работает так, как он привык работать.

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

Нарабатывать умение концентрироваться на неприятных и неинтересных вещах делается таким же способом - стараетесь через силу регулярно это делать. Через несколько лет мозг привыкнет к новому поведению.
Можно это назвать силой воли - умение осознанно приспособиться к некомфортным условиям.

P.S. С детства такие вещи тренируются. Чем взрослее тем сложнее, и даже факт того что ты осознаешь конкретный недостаток не облегчает того, что избавиться от него тяжело.