Keyboard Time: 10 mins, Automation Wait Time: 10 mins
Scenarios: Instructor-Led, Self-Paced
In this scenario we have a branch review environment and production environment for the Application Build Project. If the Application Build Project is used only by the same environment types which are also directly managed by the same DevOps team as the Application Build Project, then it may make sense to ensure there is enough testing in the Application Build Project that Environment Deployment Projects can simply ship the application to production (disable staging).
However, if the artifacts (container in this case) of the Application Build Project are used by many different types of environments and/or by Ops teams that have seperation of security or duties from the Application Build Project team, then there could be a lot of testing in downstream Environment Deployment Projects as well.
Open ‘yourpersonalgroup/hello-world’
On the left navigation, Click Merge Requests
Click [your merge request (“Updating color”)]
The information in the main body of the merge request is what is contstantly updated. Approvals also have to be given when they are configured.
We are going to pretend you’ve gotten your code running, resolved all CI checks, addressed all MR feedback and gotten the sufficient approvals to merge.
If you are NOT in an instructor-led class, you could revert the container version changes and after the CI runs, see that you no longer have vulnerabilities in your MR view.
In the main page body, Click* **Merge** (button)
On the left navigation, Click CI/CD => Pipelines
One pipeline starts with your merge request name - when a branch is merged, the previous pipeline’s “stop_review” job is run to destroy the review environment and prevent test environment sprawl.
The other pipeline starts with ‘Merge branch’ and is for the merge into the default branch and it will push the changes through both a staging and production environment.
[Automation wait: ~1 min] Wait for the shorter pipeline to complete.
On the left navigation, Click Deployments => Environments
Notice the ‘review/<your_mr_branch_name>’ review app is gone - it was removed by the MR pipeline running “stop_review” when you merged to main.
To return to the pipeline list, Click [the browser back button]
To open the “Merge branch…” pipeline page, Click [the Status badge] or [the pipeline #]
[Automation wait: ~2 min] Wait until the pipeline starting with “Merge branch…” has a status of ‘blocked’ (meaning pressing play is required to continue) or in the pipeline details page you can see that the ‘production’ job is complete
On the left navigation, Click Deployments => Environments
Next to ‘production’ Click Open
The production environment should have the new background color.
In the browser tabs, Click Environments
On the left navigation, Click CI/CD => Pipelines
To open the blocked pipeline starting with ‘Merge branch…’ Click [the Status badge] or [the pipeline #]
[Automation wait: ~5 min] Wait for [the play icon] to appear on the ‘promote-image-to-latest’ job. Hitting the browser refresh button helps ensure your status display is accurate.
You may have to wait for the ‘browser_performance’ CI test job to complete before [the Play button] appears on the ‘promote-image-to-latest’ job.
IMPORTANT: Once it is available on the job ‘promote-image-to-latest’ Click [the Play button]
Keyboard Time: 10 mins, Automation Wait Time: 5 mins Scenarios: Instructor-Led, Self-Paced
Open ‘yourpersonalgroup/world-greetings-env-1’
You will now take the change in the World Greeting Environment Deployment Project.
Click CI/CD => Schedules
On the right of CheckForNewContainerVersion Click [the play button]
If there are no scheduled pipelines, just navigate to CI/C => Pipelines and Click Run pipeline and Click Run pipeline
On the left navigation, Click CI/CD => Pipelines
On the latest pipeline Click [the Status badge] or [the pipeline #]
Wait until the Child deploy pipeline has a status of ‘blocked’ indicated by the gear icon (meaning manual action is needed)
Expand the Downstream pipeline with the great than arrow (>).
[Automation wait: ~3 min] Wait until the update-staging-manifests job has a green check next to it
On the left navigation, Click Deployments => Environments
Next to ‘staging’ Click Open
The staging environment should have the new background color.
In the browser tabs, Click Environments
Next to ‘production’ Click Open
The production environment should still have the original background color.
In the browser tabs, Click Environments
On the left navigation, Click CI/CD => Pipelines
To open the blocked pipeline, Click [the Status badge] or [the pipeline #]
Expand the Downstream pipeline with the great than arrow (>).
Next to the ‘update-production-manifests’ job, Click [the play button]
[Automation wait: ~5 min] Wait for the GitLab deployment to production to complete successfully and wait ~ 3 more minutes for the GitLab Agent to perform a GitOps CD Pull.
On the left navigation, Click Deployments => Environments
Next to ‘production’ Click Open
The production environment should have the new background color.
This is your change in the actual production environment. Keep in mind there could be many Environment Deployment Projects that consume the Application Build Project ‘hello-world’ container image. They could be using schedules, manual triggering by running pipelines or merge requests. For the supported methods in these working example projects you can read more here.