GitLab Speed Runs, 29 Dec 2019

Previous Meeting

⏯

youtube image

►

From YouTube: Speed-run - Configuring Review Apps (website)

Description

This is a demo to show how to configure a review app through the .gitlab-ci.yml file

A

Hello, my name is Erica Lewinsky and I'm the product manager for the early stage good lab today, I want to talk a little bit about review apps on how you can configure them after you already have a working project, so once we have configured a basic staging and production environment as part of continuous delivery, it would be nice to review the changes on an actual system before going to staging. This is called a dynamic environment or what we call review apps we get lab.

A

This creates an environment prayer emerge request. This is valuable not only for developers but also QA product owners, product designers, anyone that is interested in seeing what the new feature looks like, and you can just simply send a link and ask for feedback in this demo. I will show you how to add a review app after the project is already configured for this simple example: I'm using a surge, dot, sh and Gatsby. That is an easy way to get a static website up and running.

A

So if we look at my project, you can see that it's already configured and it's deploying to staging and production environments. So we can see that's here in environments and you can see I have a production of production and the staging environment. Now the part the pipeline that I have configured looks a little bit like this.

A

And you can see, I have different stages, build test deployed, staging deploy to production and, lastly, production tests.

A

We can also look at the merger quest that I've done in this project and the last one you can see it was deployed to staging and also the plights of production. We can see of the app itself. So we can see this is our staging environment, and this is our production environment. And now what I want to do is show how you can configure a review up environment to check your changes before it goes to staging, and then it will also change one of the files and see what it looks like.

A

So, in order to configure this we'll need to add a new job and environment to our get labs, CI mo file, so.

A

Let's open the file- and you can see here, we have the build website. We have some testing phases, deploy to staging of the production production tests and that's basically it so before I add before the production, the pre-production stage before staging we're going to add a new job.

A

So, let's edit file and here before, deploy staging we're going to add, deploy, review, we're adding a deploy review stage.

A

So we have the stage configured and we have the job configured, deploy, review and you'll notice that it goes only on branches. It works only on branches, which means that whenever I deploy to master, this job is not going to be initiated. But when I create a branch that's created through the merger quest, it will be called on, and since this is a dynamic environment, we're gonna use some predefined Burney go.

A

So you can see here in the name we have CI commit ref name and in the URL we have our basic domain name and an additional predefined, CI environment, slug name and will also notice for the actual deployment that we're also using the deployment to the domain name and again CI environment slug. So this is really important to notice.

A

And now you will commit our changes.

A

Then, let's create added a review, app stage and Lola pikas in the merger quest and submit it, and we can see that the pipeline is already running.

A

If we peek up the pipeline, we'll see that we have a new stage, it's called the core review. The other stages that we had for deploy, staging and deploy production production tests are not here because those are defined only to use to work on master, and this is defined only to work on branches.

A

So we'll wait for the pipeline to complete.

A

While we're waiting for the pipeline to complete I want to show you that, if we go back to the merge request itself, we will see another change. That says that this merge request branch will deploy to this name, which is going to be our URL for the reviewing.

A

And now that our pipeline has succeeded, we now have a review up if we go back to the merger quest.

A

A

We can now see the button that says view app and pressing. It will bring us to a new environment. As you can see, the name is review pouch and it's our new review at well. While this is our production, our pre-production pages, if we go back to environments, we'll see that we now have a new environment in addition to the staging and production that we had before we had our new review patch.

A

Okay, so from the merger quest when we saw the deployed review patch environment, what we're going to do is since we're happy with the way it looks, we're going to merge it for us to master you.

A

Once it's merged to master, we can see the new pipeline that's running and it goes back to our.

A

Deploying to production, we have now a new stage, build test, deploy review to play, staging deploy, production and production tests. So, of course, this is our additional step.

A

We're gonna go ahead and wait for the pipeline to complete.

A

Now that the pipeline is passed and we now have a review app also in master, let's go ahead and make a change in a file and make sure that we can see this before it gets to production. So I'm going to go to the repository, it's a file source.

A

Pages index we're gonna go ahead and edit it with a web ID, and you can see that the title of the page- and this is a new title, which is what we saw here and we'll change it to this. The best title ever just so that we can visually see the change and we're gonna go ahead and commit which is going to create a new merge request and therefore it's going to deploy it again to the review app. So change title and let's copy here.

A

And we submitted the merger quest and now again we can see the pipeline is running and we can see that it's going to deploy now it's a different URL to another branch name and let's open the pipeline and wait for it to complete again.

A

Okay, so our pipeline is completed. Let's go back to the merger list.

A

And click on view app and we can see our new title has been changed. If we go back to our production and refresh the website, you'll see it's still. The old title same goes for staging and only after we actually merge the merger quest into master.

A

And so we'll take a look again at the pipeline and we'll see again all the different stages and jobs. Only after this we're gonna see the change in pre-production first and then production. So let's go ahead and wait for the pipeline to complete.

A

Okay, it's good evening environment. So, let's see good job and now on. The pipeline is just waiting for a manual and to rate their intervention for deployment to production and we'll wait for that.

A

Okay and now it's in production, so let's refresh and you can see we got all the changes throughout the review, apps staging and production. So, as you can tell, this is a pretty feature. It's very valuable. You can get a lot of feedback before at the point to your know, sites staging and production and I hope. You found this helpful.