Learning note / Reflections on my studies
DevOps Practices
DevOps connects the code on a developer's machine with the version another person needs to run. The part that interests me is making that path understandable and repeatable.
The work around the code
A change needs more than an implementation. Someone needs to know which version it belongs to, how it was checked, and what needs to happen before it can be used.
I think of version control, build steps, and configuration as ways of making those expectations explicit for the next person.
Repeatability is the useful goal
A container or pipeline is useful when it removes an unclear manual step. It is less useful if it simply moves that uncertainty into a configuration file nobody understands.
The question I come back to is whether another person could follow the same process and get a result they can verify.
Keeping delivery connected to feedback
Checks before a release and signals after it serve different purposes. I want both: evidence that a change behaves as intended, and a way to notice when real use reveals something that the checks missed.
What I take forward
- Make delivery steps explicit.
- Automate a process that can first be explained.
- Keep verification and operating feedback connected.