Installation Script Scope And Management Policy Guide

by SLV Team 54 views
Installation Script Scope and Management Policy Guide

Hey guys! Let's dive into defining the scope and management policies for our installation scripts. This is super important to keep our projects organized and efficient. We need to nail down what falls under our responsibility, how these scripts should be handled, and what the update rules are. So, let's break it down and make sure we're all on the same page!

Overview

This article outlines the scope and management policies for installation scripts within this repository. To ensure clarity and consistency, we need well-defined guidelines on which tools should have installation scripts, how these scripts should be managed, and the applicable upgrade policies. This will help us maintain a streamlined and efficient development environment.

Scope Categories

To better manage our installation scripts, we've categorized them into three main groups. Each category has its own set of policies and guidelines, ensuring that we handle each type of tool appropriately. Let's get into the details of each category so you know exactly what's up!

1. System Dependencies (NOT Directly Managed)

Description: These are the components that you can easily install using system package managers like apt or brew. Version control isn't a big deal for our development use cases here, so we keep it simple. These are the everyday tools that most systems already have or can easily grab without extra fuss. Think of them as the basic building blocks.

Policy:

  • ❌ No dedicated installation scripts in this repo – We don't need to reinvent the wheel!
  • ✅ Can be installed as dependencies when our scripts need them – Easy peasy.
  • ✅ Use the system’s preferred package manager (apt, brew, etc.) – Keep it native and simple.

Examples: wget, curl, jq, git, tar – The usual suspects.

Implementation:

We use the install_command function from functions.sh, which smartly uses the OS-specific package manager. This keeps our scripts clean and platform-agnostic. This function is a lifesaver because it handles the nitty-gritty details of figuring out which package manager to use on different operating systems. We don't want to be writing separate install commands for every OS, do we?

# In our scripts, we can do:
install_command wget jq curl

This is super handy because it means our scripts stay clean and readable. We just list the tools we need, and the function takes care of the rest. It's like having a magic wand for dependencies!

2. Third-Party Package Manager Tools (Install Only, Don't Upgrade)

Description: These components need custom package managers or adding external sources/PPAs to your system. Think of the trickier installs that aren't just a simple apt install away. We're talking about tools that have their own way of doing things, and we need to respect that.

Policy:

  • ✅ Our scripts will install them (one-time setup) – We handle the initial heavy lifting.
  • ❌ Our scripts will NOT upgrade them – That's their package manager's job.
  • ✅ Once installed, upgrades are managed by their own package managers – Let them do their thing.
  • ℹ️ Users should use the tool's native upgrade mechanisms – Keep it consistent and clean.

Examples:

  • Docker (needs Docker's apt repository)
  • Kubernetes tools that use their own repositories
  • Tools installed via snap, flatpak, or other third-party package managers

Rationale:

These tools come with their own update channels and mechanisms, so we don't want to mess with that. We'll handle the initial setup, which can sometimes be a bit complex, but we leave the ongoing management to their native systems. It’s like setting up a new gadget and then letting it handle its own software updates. We just want to make sure it's plugged in and ready to go.

3. Custom/Version-Controlled Installations (Fully Managed) ⭐

Description: This category is for components with custom installation procedures or where we want to explicitly control the version. This is where we roll up our sleeves and get hands-on. We're talking about tools that need a bit more love and attention to get them installed just right. These are often the core tools that we need to be super precise about.

Policy:

  • ✅ Full installation scripts using the new framework – We're in charge here.
  • ✅ Support for version specification (install specific versions) – Pin those versions down!
  • ✅ Support for upgrades and downgrades – Flexibility is key.
  • ✅ Downloadable from GitHub releases, official websites, or archives – We're resourceful.
  • ✅ Typically installed to /opt with versioned directories – Keep things tidy.
  • ✅ PATH management via /etc/profile.d/ (Linux) or equivalent – Make sure they're easily accessible.

Examples:

  • kubectl (direct binary download)
  • Terraform (HashiCorp releases)
  • GraalVM (custom JDK distribution)
  • Helm (GitHub releases)
  • k6 (GitHub releases)
  • Maven (Apache archives)
  • Go (official Go downloads)

Key Characteristics:

  • Scripts can accept version parameters: ./install_kubectl.sh 1.28.0 – Specify exactly what you need.
  • No version parameter = install latest – Default to the newest and shiniest.
  • Can upgrade: ./install_kubectl.sh 1.29.0 (replaces existing) – Stay up-to-date.
  • Can downgrade: ./install_kubectl.sh 1.27.0 (replaces existing) – Go back if needed.

This category gives us the most control. We can specify exact versions, upgrade, and downgrade as needed. It's all about making sure we have the right tools, right where we need them. The version parameter support is crucial because it allows us to test specific versions or roll back if a new version introduces issues. Think of it as our safety net.

Upgrade Facility

Okay, so now that we've got our tools installed, how do we keep them up-to-date? We need a solid upgrade facility that makes it easy to keep everything current, but also respects our version pinning. Let's map out what this facility needs to do.

Requirements

We're going to create a facility script (e.g., upgrade_all.sh) that does the following:

  1. Upgrades all custom-installed tools to the latest versions

    • It scans for all installation scripts in the repo.
    • Then, it re-runs each script without version parameters (which grabs the latest).
    • BUT, it skips tools that were pinned to specific versions. We don't want to accidentally upgrade something that needs to stay put.

  2. Version pinning mechanism

    • We need a way to track which tools were installed with specific versions.
    • Pinned tools should be skipped during bulk upgrades. This is super important!
    • One way to do this is by storing installation metadata in a config file or a database. We'll dig into storage options in a bit.

  3. Updates system package managers

    • On Linux: sudo apt update && sudo apt upgrade -y – Keep those system packages fresh.
    • On macOS: brew update && brew upgrade – Gotta love Homebrew.
    • This updates all those Category 1 dependencies we talked about earlier.

  4. Reports on Category 2 tools

    • It lists tools installed via third-party package managers.
    • It reminds users to upgrade them manually or via their native managers. We're just giving them a nudge in the right direction.
    • For example: