"എന്റെ മെഷീനിൽ പ്രവർത്തിക്കുന്നു", നിക്സുമായി പരിഹരിക്കപ്പെട്ടോ?

ഓരോ ടീമിനും ഓരോ സംഭാഷണമുണ്ട്. "എന്റെ ബിൽഡ് പരാജയപ്പെട്ടു". "എന്റെ മെഷീനിൽ പ്രവർത്തിക്കുന്നു". പിന്നെ ഇരുപത് മിനിറ്റ് വേരിയൻറ് താരതമ്യം: വ്യത്യസ്ത ടെറാഫോർം, പുതിയ നോഡ്, പഴയ കുബെക്ട്ൽ, മാക് ഒഎസിനൊപ്പം വന്ന പൈത്തൺ, കാണാതായ സിസ്റ്റം ലൈബ്രറി.

പുതിയ ടീം അംഗത്തെ കൂട്ടിച്ചേര് ക്കാന് ഒരു ദിവസം എടുത്തേക്കാം ശരിയായ ഉപകരണങ്ങള് ശരിയായ പതിപ്പില് കിട്ടാന് മാത്രം. ഐ. സി. പലപ്പോഴും തികച്ചും വ്യത്യസ്തമായ പതിപ്പുകൾ ഉപയോഗിക്കുന്നു.

പുനർനിർമ്മിക്കാവുന്ന വികസന പരിതസ്ഥിതികൾ ഇത് പരിഹരിക്കുന്നു. അവരെ കിട്ടാനുള്ള ഏറ്റവും ശക്തമായ മാർഗ്ഗം നിക്സാണ്, പുതിയ ഉപകരണങ്ങൾ അത് കൂടുതൽ ആക്സസ് ചെയ്യാവുന്നതാക്കി.

പ്രശ്നം

വികസന പരിതസ്ഥിതികൾ മാറുന്നു കാരണംഃ

• എല്ലാവരും വ്യത്യസ്തമായി ടൂളുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു: ഹോംബ്രൂ, അപ്റ്റ്, ഡൌൺലോഡ് ചെയ്ത ബൈനറികൾ, പതിപ്പ് മാനേജർമാർ.
• പതിപ്പുകൾ അറ്റാച്ചുചെയ്തിട്ടില്ല, അല്ലെങ്കിൽ ആരും പിന്തുടരാത്ത ഒരു README-ലാണ് അറ്റാച്ച് ചെയ്തിരിക്കുന്നത്.
• ഉപകരണങ്ങൾ സിസ്റ്റം ലൈബ്രറികളെ ആശ്രയിച്ചിരിക്കുന്നു, അത് മെഷീനുകൾക്കിടയിൽ വ്യത്യാസപ്പെടുന്നു.
• CI ചിത്രങ്ങള് ഡെവലപ്പര് സ്ടെപ്പുകളിൽ നിന്നും വേറിട്ടു സൂക്ഷിക്കുന്നു.

നമുക്ക് വേണ്ടത്: റിപ്പോസിറ്ററിയിൽ ഒരു ഫയൽ, ഏത് ഉപകരണങ്ങൾ (വെർഷനുകൾ) ആണ് പ്രോജക്ടിന് വേണ്ടത് എന്ന് കൃത്യമായി നിർവചിക്കുന്ന, എല്ലാ ഡവലപ്പർമാരുടെയും മെഷീനിലും CI യിലും ഒരേപോലെ പ്രവർത്തിക്കുന്ന.

ഒരു ഖണ്ഡികയില് നിക്സ

നിക്സ് ഒരു റാഡിക്കൽ ആശയത്തെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു പാക്കേജ് മാനേജറും ബിൽഡ് സിസ്റ്റവുമാണ്: ഓരോ പാക്കേജും അതിന്റെ ഇൻപുട്ടുകളുടെ കൃത്യമായ വിവരണത്തിൽ നിന്ന് ഒറ്റപ്പെട്ട് നിർമ്മിക്കുകയും ആ ഇൻപുട്ടുകൾ (അത്തരം) /nix/store/abc123-terraform-1.9.8) പലതരം പതിപ്പുകൾ പരസ്പരം പൊരുത്തപ്പെടാതെ ജീവിക്കുന്നു. ഒന്നും ആഗോളതലത്തിൽ സ്ഥാപിച്ചിട്ടില്ല. രണ്ട് മെഷീനുകൾ ഒരേ നിക്സ് വിവരണം ഉപയോഗിച്ചാൽ, അവയ്ക്ക് കൃത്യമായി ഒരേ സോഫ്റ്റ്വെയർ ലഭിക്കും, ബിറ്റ് ബിറ്റ്. നിക്സ്പ്കഗ്സ് ഈ ശേഖരത്തില് 100,000 പാക്കേജുകള് കൂടുതലുണ്ട്. പാക്കേജ് മാനേജര് മാരില് ഏറ്റവും വലിയ പാക്കേജിന് റെ കൂട്ടത്തില് ഒന്നാണിത്.

നിക്സ് പരുത്തി

പരുത്തി എല്ലാം കൃത്യമായി ക്രമീകരിക്കുന്ന ഒരു ലോക്ക് ഫയൽ ഉപയോഗിച്ച് നിക്സ് പ്രോജക്ടുകളെ നിർവചിക്കാനുള്ള ആധുനിക മാർഗമാണ്. ഒരു ഇൻഫ്രാസ്ട്രക്ചർ പ്രോജക്ടിന് വേണ്ടിയുള്ള ഒരു ഡെവലപ്പർ ഷെൽ:

{
  description = "Infrastructure dev environment";

  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

  outputs = { self, nixpkgs }:
    let
      systems = [ "x86_64-linux" "aarch64-linux" "aarch64-darwin" ];
      forAll = f: nixpkgs.lib.genAttrs systems (s: f nixpkgs.legacyPackages.${s});
    in {
      devShells = forAll (pkgs: {
        default = pkgs.mkShell {
          packages = with pkgs; [
            opentofu
            kubectl
            kubernetes-helm
            awscli2
            jq
            shellcheck
          ];
        };
      });
    };
}

ഓടിപ്പോകുക. nix develop, നിങ്ങള് ആ ഉപകരണങ്ങളുമായി ഒരു ഷെല്ലിലായിരിക്കും. flake.lock ഫയൽ അവയെ പിൻ ചെയ്യുന്നു, അങ്ങനെ എല്ലാവരും ഒരേ പതിപ്പുകൾ ലഭിക്കുന്നു ആരെങ്കിലും മനഃപൂർവ്വം ലോക്ക് അപ്ഡേറ്റ് ചെയ്യുന്നതുവരെ.

സത്യസന്ധമായി, നിക്സിന്റെ ഭാഷയ്ക്കും ആശയങ്ങൾക്കും ഒരു കുത്തനെയുള്ള പഠന വക്രമുണ്ട്. അവിടെയാണ് കൂടുതൽ സൌഹൃദ ഉപകരണങ്ങൾ വരുന്നത്.

നിക്സിനെ ഉപയോഗിക്കുക എന്നതല്ല ലക്ഷ്യം. "ഉപകരണങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുക" എന്ന കമാൻഡ് എപ്പോഴും ഒരേ ഫലം നൽകുന്ന ഒരു കമാൻഡായി മാറുകയാണ് ലക്ഷ്യം.

devbox, devenv: വേദനയില്ലാതെ നിക്സ്

devbox (ജെറ്റിഫൈയിൽ നിന്നും) നിക്സ് ഉപയോഗിക്കുന്നു, പക്ഷേ നിങ്ങൾ ഒരു ലളിതമായ ജെസോൺ ഫയൽ മാത്രം എഴുതുന്നു:

{
  "packages": [
    "opentofu@1.10",
    "kubectl@1.33",
    "helm@latest",
    "awscli2@latest",
    "jq@latest"
  ],
  "shell": {
    "init_hook": ["echo 'Infra shell ready'"]
  }
}

devbox shell

നിക്സ് അറിവ് ആവശ്യമില്ല. ഒരേ ഫയലിൽ നിന്നും ഡോക്കർ ഫയലുകളും ഡെവ് കണ്ടെയ്നർ കോൺഫിഗറേഷനുകളും സൃഷ്ടിക്കാനും ഇതിന് കഴിയും.

വിഭജനം (Cachix ൽ നിന്ന്) മറ്റൊരു ജനപ്രിയ ഓപ്ഷനാണ്ഃ കൂടുതൽ നിക്സ് ഹൂഡിനടിയിൽ, എന്നാൽ ഭാഷകൾക്കും സേവനങ്ങൾക്കുമായി തയ്യാറാക്കിയ മൊഡ്യൂളുകൾ (ലോക്കൽ പോസ്റ്റ്ഗ്രെഎസ്.സി.എൽ. തുടങ്ങുന്നത് പോലെ), പ്രീ-കമ്മിറ്റ് ഹുക്കുകൾ, സ്ക്രിപ്റ്റുകൾ എന്നിവ ഉപയോഗിച്ച്.

രണ്ടും നന്നായി പ്രവർത്തിക്കുന്നു ഡെര് വ്, നിങ്ങൾ ഓട്ടോമാറ്റിക്കായി പരിസ്ഥിതി സജീവമാക്കുന്നു cd പ്രോജക്ട് ഫോൾഡറിലേക്ക്

പകരം ഡെവ് കണ്ടെയ്നറുകൾ?

പ്രധാന ബദല് ഡെവ് കണ്ടെയ്നറുകൾ: a devcontainer.json നിങ്ങളുടെ എല്ലാ ഉപകരണങ്ങളുമായും ഒരു കണ്ടെയ്നർ ഇമേജ് നിർവചിക്കുന്നു, അത് വിഎസ് കോഡ്, ജെറ്റ് ബ്രെയിൻസ് ഐഡിഇ, ഗിറ്റ്ഹബ് കോഡ്സ്പേസുകൾ തുടങ്ങിയവ ഉപയോഗിക്കുന്നു.

	നിക്സ് / ഡെവ്ബോക്സ് / ഡീവൺ	ഡെവ് കണ്ടെയ്നറുകൾ
റൺസ്	നിങ്ങളുടെ മെഷീനിൽ പ്രാദേശികമായി	ഒരു കണ്ടെയ്നറിനുള്ളില്
പുനർനിർമ്മാണ ശേഷി	വളരെ ഉയർന്ന (ലോക്ക് ചെയ്ത ഇൻപുട്ടുകൾ)	ചിത്രം എങ്ങനെ നിർമ്മിക്കപ്പെടുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു
മാകോസ് ലെ പ്രകടനം	പ്രാദേശിക വേഗത	ചില ഓവർഹെഡ് (ഫയൽ സിസ്റ്റം, വിഎം)
പഠന വക്രത	കുത്തനെയുള്ള (Nix), എളുപ്പമുള്ള (devbox)	ഡോക്കറിനെ അറിയുന്നതുകൊണ്ട് എളുപ്പമാണ്.
എഡിറ്റർ സംയോജനം	ഡെറൻവ് വഴി, എല്ലായിടത്തും പ്രവർത്തിക്കുന്നു	വിഎസ് കോഡിലും കോഡ് സ്പെയ്സിലും മികവ്
ക്ലൌഡ് ഡെവലപ്പർ പരിതസ്ഥിതികൾ	സാധ്യമാണ്	കോഡ് സ്പെയ്സുകളിലും സമാനമായവയിലും സ്വദേശി

രണ്ടും നല്ല തീരുമാനങ്ങളാണ്. മിക്ക ടീമുകൾക്കും ഡെവ് കണ്ടെയ്നറുകൾ പരിചിതമാണ്. നിക്സ് അടിസ്ഥാനമാക്കിയുള്ള ഉപകരണങ്ങള് കൂടുതല് കൃത്യവും നേറ്റീവ് ആയി പ്രവർത്തിക്കുന്നതുമാണ്. ചില ടീമുകൾ ഇവയെ സംയോജിപ്പിക്കുന്നു. ഒരു ഡെവലപ്പർ കണ്ടെയ്നറിനുള്ളിലെ നിക്സ്.

സിഐയിലെ നിക്സ്

യഥാർത്ഥ പ്രതിഫലം: സമാനമായ പരിസ്ഥിതി ലാപ്ടോപ്പുകളിലെ പോലെ.

- uses: cachix/install-nix-action@<sha>
- run: nix develop --command make test

അല്ലെങ്കിൽ devbox ഉപയോഗിച്ച്ഃ devbox run test. ഒരു ബൈനറി കാഷെ (കാച്ചിക്സ്, അല്ലെങ്കിൽ സ്വയം ഹോസ്റ്റുചെയ്ത ഒന്ന്) മുൻകൂട്ടി നിർമ്മിച്ച പാക്കേജുകൾ ഡൌൺലോഡ് ചെയ്യുന്നതിലൂടെ CI വേഗത്തിൽ നിലനിർത്തുന്നു.

"എന്റെ ലാപ്ടോപ്പിനേക്കാൾ വ്യത്യസ്തമായ ടെറാഫോം പതിപ്പാണ് ഐസിഐയുടെ ചിത്രത്തിലുള്ളത്" എന്നൊന്നും വേണ്ട.

നീയത് പരീക്ഷിക്കണോ?

നിങ്ങളുടെ ടീം പതിവായി സമയം നഷ്ടപ്പെടുത്തുന്നുവെങ്കിൽ പതിപ്പ് അസമത്വത്തിനും വേഗത കുറഞ്ഞ ഇൻബോർഡിംഗിനും, അതെ. ഞാന് തുടങ്ങുന്നത് devbox ഒരു റിപ്പോസിറ്ററിയില്: ഒരു ജെ എസ് ഒന് ഫയല് , ഒരു കമാന് ഡ്, നിക്സ് അറിവ് ആവശ്യമില്ല. ആളുകൾക്ക് ഇഷ്ടമായാൽ, കൂടുതൽ ആഴത്തിൽ ചട്ടിയിൽ ചേർക്കുക. നിങ്ങളുടെ ടീം ഇതിനകം വിഎസ് കോഡിൽ ജീവിക്കുന്നുണ്ടെങ്കിൽ, ഡെവ് കണ്ടെയ്നറുകൾ ഒരു നല്ല പാതയാണ്.

എന്റെ അഭിപ്രായം: നിങ്ങളുടെ പ്രോജക്ടിന്റെ ഉപകരണങ്ങൾ നിങ്ങളുടെ പ്രോജക്ടിന്റെ ഭാഗമാണ്. അവയെ സംഭരണിയിൽ ഇടുക, അവയെ കുത്തിവയ്ക്കുക, പരസ്പരം ലാപ്ടോപ്പുകൾ ഡീബഗ് ചെയ്യുന്നത് നിർത്തുക.

ഡെസ്ലി