What is a GitLab "environment" versus a software running environment?

Question

GitLab Environments consist of a name and optionally a URL, according to its docs. In my software career an "environment" HAS a name, like "production", but CONSISTS of things like operating system, installed dependencies, location, disk capacity, database connections, etc.

I have looked at GitLab docs and StackOverflow question and StackOverflow question and the closest I see is that you might have a URL that points to where your code will run. How does GitLab know how to install my software given only source and the name "staging", with an optional URL? I'm trying to get into continuous integration and deployment, using servers on my network, at a university with its hosted GitLab instance. Can anyone tell me what concepts I am missing?

EDIT:
Example: I have built and installed in the cloud a production application that hosts web-based surveys. It has functional code to present questions and process answers, which connects to a database that stores the configuration of the surveys themselves. I have built a survey management desktop app that allows creation and editing of survey content in a local file format. This app includes a "Deploy" button which connects to the production database and inserts/updates the survey specifics. I had to type in the connection string at some point, for my deployer to know where to deploy, and I had to program the SQL commands and other logic to carry out such a deployment. Less frequently, I update the functional code of the web survey app. That is a different process, in which I connect to the server vm remotely, and manually put the files where they go.

My question is about GitLab, not 3rd party alternatives and add-ons.

Do GitLab's Environments and Deployments (or other DevOps) features pertain to common situations like this?
If so, where in GitLab do I specify the myriad details (or kickoff script) about how to access the environment and execute deployments?
Where is the glue?

Answer 1

In GitLab, the Environment is a purely logical construct. You can designate CI/CD jobs as deployment jobs to various environments. You can also designate jobs to be triggered when you "stop" an environment from the GitLab UI, but you need to implement the details. GitLab also provides a "rollback" feature, which really just means to re-run an older deployment job.

GitLab stores some information and provides a little glue, but it is entirely separate from how you actually manage the contents of your environment, which you must implement in your jobs and elsewhere.

That is to say: GitLab doesn't know where to install your software. You have to implement that. GitLab's autodevops does provide some ways to easily implement deployments, especially for gitlab-managed Kubernetes clusters, but ultimately you control what your jobs do and how your environment is run. You might do something like use ansible playbooks to manage infrastructure from GitLab CI

For further reading, check out GitLab's blog: How to use GitLab CI to deploy to multiple environments.

Answer 2

Holy maloley. The glue is called ".gitlab-ci.yml". Explanation is buried here: https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html
"To use GitLab CI/CD, you need:
Application code hosted in a Git repository.
A file called .gitlab-ci.yml in the root of your repository, which contains the CI/CD configuration."

I don't know why this vital foundation isn't positioned more prominently in the docs. Documentation says you can use the UI, or the .gitlab-ci.yml file to define environments and deployments. I mistakenly assumed that meant some kind of equivalence, rather than that the UI provides only the ability to define a stub, and that you have to search elsewhere for the syntax and options for the all-important .yml file.