realaravinth/debian-mirror-gitlab
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
debian-mirror-gitlab/doc/development/testing_guide/review_apps.md
Pirate Praveen 45981217aa New upstream version 11.10.8+dfsg
2019-07-07 11:18:12 +05:30

9.3 KiB
Raw Blame History

Review Apps

Review Apps are automatically deployed by each pipeline, both in CE and EE.

How does it work?

CD/CD architecture diagram

Review Apps CI/CD architecture

Show mermaid source 
graph TD
    B1 -.->|2. once gitlab:assets:compile is done,
triggers a CNG-mirror pipeline and wait for it to be done| A2
    C1 -.->|2. once review-build-cng is done,
Helm deploys the Review App using the Cloud
Native images built by the CNG-mirror pipeline| A3

subgraph gitlab-ce/ee test stage
A1gitlab:assets:compile
B1review-build-cng -->|1. wait for| A1
C1review-deploy -->|1. wait for| B1
D1[review-qa-smoke] -->|1. wait for| C1
D1[review-qa-smoke] -.->|2. once review-deploy is done| E1>gitlab-qa runs the smoke
suite against the Review App]
end


subgraph CNG-mirror pipeline
A2>Cloud Native images are built];
end


subgraph GCP gitlab-review-apps project
A3>"Cloud Native images are deployed to the
review-apps-ce or review-apps-ee Kubernetes (GKE) cluster"];
end

Detailed explanation

  1. On every pipeline during the test stage, the review-build-cng and review-deploy jobs are automatically started.
  2. Once the gitlab:assets:compile job is done, review-build-cng triggers a pipeline in the CNG-mirror project.
    • The CNG-mirror pipeline creates the Docker images of each component (e.g. gitlab-rails-ee, gitlab-shell, gitaly etc.) based on the commit from the GitLab pipeline and store them in its registry.
    • We use the CNG-mirror project so that the CNG, (Cloud Native GitLab), project's registry is not overloaded with a lot of transient Docker images.
  3. Once the review-build-cng job is done, the review-deploy job deploys the Review App using the official GitLab Helm chart to the review-apps-ce / review-apps-ee Kubernetes cluster on GCP.
  4. Once the review-deploy job succeeds, you should be able to use your Review App thanks to the direct link to it from the MR widget. To log into the Review App, see "Log into my Review App?" below.

Additional notes:

  • The Kubernetes cluster is connected to the gitlab-{ce,ee} projects using GitLab's Kubernetes integration. This basically allows to have a link to the Review App directly from the merge request widget.
  • If the Review App deployment fails, you can simply retry it (there's no need to run the review-stop job first).
  • The manual review-stop in the test stage can be used to stop a Review App manually, and is also started by GitLab once a branch is deleted.
  • Review Apps are cleaned up regularly using a pipeline schedule that runs the schedule:review-cleanup job.

QA runs

On every pipeline during the test stage, the review-qa-smoke job is automatically started: it runs the QA smoke suite. You can also manually start the review-qa-all: it runs the QA full suite.

Note that both jobs first wait for the review-deploy job to be finished.

Performance Metrics

On every pipeline during the test stage, the review-performance job is automatically started: this job does basic browser performance testing using Sitespeed.io Container .

This job waits for the review-deploy job to be finished.

How to?

Log into my Review App?

The default username is root and its password can be found in the 1Password secure note named gitlab-{ce,ee} Review App's root password.

Enable a feature flag for my Review App?

  1. Open your Review App and log in as documented above.
  2. Create a personal access token.
  3. Enable the feature flag using the Feature flag API.

Find my Review App slug?

  1. Open the review-deploy job.
  2. Look for Checking for previous deployment of review-*.
  3. For instance for Checking for previous deployment of review-qa-raise-e-12chm0, your Review App slug would be review-qa-raise-e-12chm0 in this case.

Run a Rails console?

  1. Filter Workloads by your Review App slug , e.g. review-29951-issu-id2qax.
  2. Find and open the task-runner Deployment, e.g. review-29951-issu-id2qax-task-runner.
  3. Click on the Pod in the "Managed pods" section, e.g. review-29951-issu-id2qax-task-runner-d5455cc8-2lsvz.
  4. Click on the KUBECTL dropdown, then Exec -> task-runner.
  5. Replace -c task-runner -- ls with -it -- gitlab-rails console from the default command or
  • Run kubectl exec --namespace review-apps-ce review-29951-issu-id2qax-task-runner-d5455cc8-2lsvz -it -- gitlab-rails console and
  • Replace review-apps-ce with review-apps-ee if the Review App is running EE, and
  • Replace review-29951-issu-id2qax-task-runner-d5455cc8-2lsvz with your Pod's name.

Dig into a Pod's logs?

  1. Filter Workloads by your Review App slug , e.g. review-1979-1-mul-dnvlhv.
  2. Find and open the migrations Deployment, e.g. review-1979-1-mul-dnvlhv-migrations.1.
  3. Click on the Pod in the "Managed pods" section, e.g. review-1979-1-mul-dnvlhv-migrations.1-nqwtx.
  4. Click on the Container logs link.

Frequently Asked Questions

Isn't it too much to trigger CNG image builds on every test run? This creates thousands of unused Docker images.

We have to start somewhere and improve later. Also, we're using the CNG-mirror project to store these Docker images so that we can just wipe out the registry at some point, and use a new fresh, empty one.

How big are the Kubernetes clusters (review-apps-ce and review-apps-ee)?

The clusters are currently set up with a single pool of preemptible nodes, with a minimum of 1 node and a maximum of 50 nodes.

What are the machine running on the cluster?

We're currently using n1-standard-16 (16 vCPUs, 60 GB memory) machines.

How do we secure this from abuse? Apps are open to the world so we need to find a way to limit it to only us.

This isn't enabled for forks.

Other resources

Return to Testing documentation