Environments, configuration, logs
Beginner Core Git Git CLI
Why this matters
"It's merged" and "it's live" are different events, sometimes days apart. Between them the change travels through environments, gets configured for each, and writes logs when it misbehaves. If you write documentation, test, or answer customers, you need to know where a change is at any moment, and where to look when it fails.
Environments: the same program in several places
An environment is a complete place where the application runs: machines, the runtime, the configuration, and the data it talks to. Teams keep several so that mistakes are caught before real users see them.
| Environment | Who uses it | Data | Purpose |
|---|---|---|---|
| Local | one person, their own computer | fake or a small copy | writing and trying the change |
| Development (dev) | the team | fake | integrating everyone's changes, first automated checks |
| Test / QA | testers | prepared test data | verifying behaviour against requirements |
| Staging (pre-production, UAT) | testers, product, sometimes customers | a copy of real data | the dress rehearsal: identical to production |
| Production (prod, live) | real users | real data | the real thing |
Not every team has all five; small teams often have local, staging and production. The names vary, the idea does not: earlier environments are cheap to break, later ones are expensive.
Configuration: what differs between environments
The same build runs in every environment, but it needs different settings in each: which database to talk to, which web address to use, whether debugging output is on, what password to use. These settings are configuration, and they live outside the source code so that the code does not change per environment.
Two common forms:
- Configuration files:
config.yml,settings.json,application.properties. Committed when they contain no secrets; often with one file per environment. - Environment variables: named values the operating system hands to a program when it starts, such as
DATABASE_URLorTRAILGUIDE_DATA. They are set on the server, in the pipeline, or, on a developer's computer, in a file named.envthat a tool loads.
The right pattern is a committed example without values, plus an ignored real file:
DATABASE_URL=
TRAILGUIDE_API_KEY=DATABASE_URL=postgres://localhost/trailguide
TRAILGUIDE_API_KEY=sk-live-…Logs: the program's diary
When a program runs, it writes lines about what it is doing and what went wrong: logs. In a terminal they appear on screen; on a server they go to files or a logging service; in a pipeline they are the job output you can read in GitLab or GitHub.
$ python3 src/trailguide.py --region Nowhere0 trail(s)That is a log line of sorts: not an error, but information. Errors look like a block of text ending with the actual problem, for example FileNotFoundError: [Errno 2] No such file or directory: 'data/trails.csv'. The last line is usually the one to read and to paste into a bug report.
How this connects to Git
- Git holds the source, the configuration templates and the pipeline definition. It does not hold environments, deployments or logs.
- A change becomes visible in an environment only after a deployment; the pipeline usually deploys automatically to early environments and on request to production (lesson 14.6).
- Documentation often needs to say which version a behaviour applies to; that is the release (lesson 1.6).
Common mistakes
- Testing on the wrong environment. A bug "fixed" on staging still exists in production until the next deployment. Always say which environment you looked at.
- Committing a real
.env. Rotate the secret immediately; deleting the file is not enough. - Editing configuration in production by hand. The next deployment overwrites it. Configuration changes go through the repository or the platform's settings, like code.
- Reporting "it doesn't work" without logs. Attach the last 20 lines of output.
Try it yourself
Goal: produce a real error message and find the line that matters.
- In a terminal, move to your home folder with
cd ~(not the playground). - Run
python3 git-practice/trailguide/src/trailguide.py --list. - Read the output from the bottom up.
Expected result: the program still works, because it finds the data file relative to its own location. Now rename the data file temporarily: mv git-practice/trailguide/data/trails.csv git-practice/trailguide/data/trails.bak, run the command again, read the error, then rename the file back with mv git-practice/trailguide/data/trails.bak git-practice/trailguide/data/trails.csv.
Show solution
The last line of the error reads FileNotFoundError: [Errno 2] No such file or directory: '…/data/trails.csv'. Everything above it is the path the error took through the code (the "traceback"), useful to developers, noise to everyone else. The last line names the real problem: a missing file. After renaming the file back, git status shows a clean tree, because renaming and restoring an untracked change leaves nothing behind.