Автоматизация рутины разработчика: bash и PowerShell без боли

Прямой ответ

Автоматизировать стоит то, что вы делаете руками чаще раза в неделю: подготовку проекта к работе, очистку кэшей и диска, бэкап конфигов и ключей, переключение окружений, отчёты о состоянии машины. Инструмент — обычный shell: bash/zsh на Linux/macOS, PowerShell на Windows (и кросс-платформенный PowerShell 7 — один скрипт на обе ОС). Главное правило безопасности: скрипт, удаляющий файлы, сначала печатает список и спрашивает подтверждение; все пути — в кавычках; ни один секрет не хардкодится в теле скрипта.

Кандидаты на автоматизацию: готовый список

devup — подъём проекта: перейти в каталог, активировать venv, git pull, проверить .env, поднять docker-стек. Вместо 5–7 ручных шагов — одна команда.
disk-clean — гигиена диска: кэши pip/npm/Docker, старые логи; на ноутбуке это регулярная операция (соседние статьи расхода: node_modules, Python-окружения).
backup-dev — бэкап конфигурации: dotfiles, .ssh-ключи, .env-файлы проектов в зашифрованный архив; правила обращения с секретами — в статье про .env и секреты.
newproject — скелет проекта: структура каталогов, .gitignore, .env.example, venv, первый коммит. Шаблон гарантирует, что .gitignore существует до первого коммита.
Отчёты состояния: версии тулчейна, свободное место, запущенные контейнеры — одним выводом для утреннего стендапа или диагностики.

Безопасный шаблон bash-скрипта

#!/usr/bin/env bash
set -euo pipefail          # стоп на ошибке, на unset-переменной, на падении в пайпе

readonly CACHE_DIR="${XDG_CACHE_HOME:-$HOME/.cache}"
echo "Будет очищено: $(du -sh "$CACHE_DIR" 2>/dev/null | cut -f1) в $CACHE_DIR"
read -r -p "Продолжить? [y/N] " ans
[[ "$ans" == "y" ]] || { echo "Отменено"; exit 0; }

find "$CACHE_DIR" -mindepth 1 -maxdepth 1 -mtime +30 -print -exec rm -rf {} +
echo "Готово"

Что здесь важно и почему:

set -euo pipefail — скрипт не продолжает работу после ошибки; половина «страшных» историй с rm — это скрипты без этой строки;
все переменные в двойных кавычках — путь с пробелом без кавычек превращает одну команду удаления в две;
подтверждение перед разрушительным действием и -mtime +30 — удаляем только старое;
#!/usr/bin/env bash, а не /bin/sh — предсказуемое поведение (sh на разных системах разный).

PowerShell: те же принципы, свой синтаксис

#Requires -Version 5.1
$ErrorActionPreference = 'Stop'

$targets = Get-ChildItem "$env:LOCALAPPDATA\npm-cache" -ErrorAction SilentlyContinue
$size = ($targets | Measure-Object Length -Sum).Sum / 1MB
"Кэш npm: {0:N0} МБ" -f $size
if ($PSCmdlet.ShouldContinue("Очистить?", "Подтверждение")) {
    Remove-Item "$env:LOCALAPPDATA\npm-cache\*" -Recurse -Force
}

Практические заметки для Windows-ноутбука:

Execution Policy: для своих скриптов достаточно Set-ExecutionPolicy -Scope CurrentUser RemoteSigned (на уровне пользователя, без админ-прав).
PowerShell 7 (winget install Microsoft.PowerShell) — кросс-платформенный и быстрее штатного 5.1; скрипты для командных задач пишите совместимыми с обоими или явно под 7.
Планировщик заданий (Task Scheduler) — для регулярного: еженедельная очистка кэшей, бэкап dotfiles; триггер «при простое» не мешает работе.
WSL-пользователям: bash-скрипты вызываются из PowerShell как wsl ~/bin/devup — одна автоматизация на оба мира.

Типичные ошибки новичков

Скрипт без set -e: первая ошибка не останавливает выполнение, и rm -rf "$DIR"/ с пустой переменной уходит не туда. Кавычки + проверка переменной ([[ -n "$DIR" ]]) — обязательны.
Интерактивные команды в автоматизации: docker login, sudo с паролем, гит с креденшиалами — в скриптах используют токены/агенты, а секреты читают из окружения.
Отладка на проде данных: сначала прогон на тестовой папке (-print вместо -exec rm), потом боевой запуск.
Скрипты без версионирования: храните их в ~/bin внутри git-репозитория — история правок спасает, когда «вчера работало».
Молчаливость: скрипт обязан печатать, что делает (что удалит, что пропустит) — иначе через месяц вы не доверитесь своему же инструменту.

Готовый пример: скрипт devup для подъёма проекта

Соберём правила в полезный инструмент — одна команда вместо утренней рутины:

#!/usr/bin/env bash
set -euo pipefail

PROJECT_DIR="${1:?Укажите каталог проекта}"
cd "$PROJECT_DIR"

[[ -d .venv ]] || python3 -m venv .venv
# shellcheck disable=SC1091
source .venv/bin/activate
pip install -q -r requirements.txt

if [[ -f .env ]]; then
    echo "OK: .env на месте"
else
    echo "ВНИМАНИЕ: нет .env — скопируйте из .env.example" >&2
fi

git pull --ff-only
if command -v docker >/dev/null && [[ -f compose.yaml ]]; then
    docker compose up -d db redis 2>/dev/null || echo "Docker-стек не поднят (проверьте вручную)"
fi

echo "Проект готов: $(basename "$PROJECT_DIR")"

Что здесь демонстрируется как принципы: аргумент обязателен и проверяется (:?); каждое действие идемпотентно (venv создаётся только если нет; зависимости доустанавливаются тихо); отсутствие .env — предупреждение, а не падение; docker — опционален и не ломает скрипт. Такой скрипт безопасно запускать повторно в любом состоянии проекта.

Храните коллекцию в ~/bin (или ~/.local/bin) внутри git-репозитория с коротким README по каждому инструменту: через полгода вы не вспомните флаги, а README и --help внутри скрипта спасут. На Windows те же сценарии — PowerShell-функции в $PROFILE или скрипты .ps1 в каталоге из PATH.

FAQ

Bash или Python для автоматизации? До ~50 строк и файловые операции — shell быстрее пишется. Сложная логика, API, парсинг JSON — Python с subprocess/pathlib. Комбинируйте: shell-обёртка вызывает Python там, где нужно.

Стоит ли учить оба (bash и PowerShell)? Разработчику на Windows — да, минимум чтение: половина корпоративных инструкций в PowerShell. Глубокое владение нужно одно; второе — на уровне «написать и понять».

Как запускать скрипты по расписанию на ноутбуке? Linux — cron/timer systemd (учтите: ноутбук должен быть включён); Windows — Task Scheduler с триггером «при входе» или «по расписанию при питании от сети».

Нужны ли алиасы вместо скриптов? Алиасы — для однострочников (alias gs='git status'). Как только появляется логика, условия и подтверждения — это файл-скрипт в ~/bin, а не строка в .bashrc.

Нужно ли логировать работу скриптов? Для разрушительных и фоновых задач — да: exec >>"$HOME/.local/state/cleanup.log" 2>&1 в начале скрипта даст историю «что и когда удалялось», и при разборе инцидента вы увидите последнюю команду. Для интерактивных инструментов лог избыточен — достаточно понятного вывода на экран.

Как тестировать скрипты до доверия? Два приёма: запуск с «сухим» режимом (флаг --dry-run, который печатает команды вместо выполнения — стандарт для утилит вроде rsync) и прогон на песочнице: скопируйте пару папок в /tmp и выполните полный цикл там. Скрипт, который вы ни разу не прогнали на тестовых данных, в бою удивит.

Что НЕ стоит автоматизировать

Автоматизация вредна, когда скрывает смысл операции или создаёт ложное чувство контроля. Не заворачивайте в скрипт: деструктивные git-операции (push --force, reset --hard) — их стоит выполнять осознанно руками; массовые обновления продакшена без review; действия с данными, у которых нет бэкапа. Правило простое: скрипт берёт на себя рутину с предсказуемым результатом, а решения с необратимыми последствиями оставляет человеку. Хороший признак зрелой автоматизации — каждый скрипт можно безопасно запустить дважды подряд, и второй запуск не сломает результат первого (идемпотентность).

Источники: справочник GNU Bash, Microsoft Learn PowerShell 101, Google Shell Style Guide (ссылки в шапке).

Автоматизация рутины разработчика: bash и PowerShell скрипты, которые экономят часы