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

While "it is entirely separate from how you actually manage the contents of your environment", as sytech in his answer, GitLab 17.6 (November 2024) does propose:

Display release notes on deployment details page

Have you ever wondered what might be included in a deployment you’ve been asked to approve?
In past versions, you could create a release with a detailed description about its content and instructions for testing, but the related environment-specific deployment did not show this data.

We are happy to share that GitLab now displays the release notes under the related deployment details page.

Because GitLab releases are always created from a Git tag, the release notes are shown only on deployments related to the tag-triggered pipeline.

This feature was contributed to GitLab by Anton Kalmykov. Thank you!

See Documentation and Issue.

And:

See GitLab 17.8 (January 2025)

List the deployments related to a release

While GitLab has long supported creating releases from Git tags and tracking deployments, this information previously lived in multiple separate places that were difficult to piece together. Now, you can see all deployments related to a release directly on the release page. Release managers can quickly verify where a release has been deployed and which environments are pending deployment. This complements the existing deployment page integration that shows release notes for tagged deployments.

We would like to express our gratitude to Anton Kalmykov for contributing both features to GitLab.

See Documentation and Issue.

---

So if you have a deployment approval process, the environment's "deployment details" page now surfaces the actual release notes. No more guesswork about what is changing.

You can open the "release" page in GitLab and see all deployments. You can also link specific changes, commits, or instructions to the environment deployment. Ff you have multiple people reviewing or manually approving a final production push, that should help.

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.

Answer 3

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.