[{"data":1,"prerenderedAt":819},["ShallowReactive",2],{"/en-us/blog/top-10-gitlab-hacks":3,"navigation-en-us":40,"banner-en-us":451,"footer-en-us":461,"blog-post-authors-en-us-Michael Friedrich":700,"blog-related-posts-en-us-top-10-gitlab-hacks":714,"blog-promotions-en-us":757,"next-steps-en-us":809},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":25,"externalUrl":26,"featured":14,"heroImage":19,"isFeatured":14,"meta":27,"navigation":28,"path":29,"publishedDate":20,"rawbody":30,"seo":31,"slug":13,"stem":35,"tagSlugs":36,"tags":38,"template":15,"updatedDate":26,"__hash__":39},"blogPosts/en-us/blog/top-10-gitlab-hacks.yml","Top ten GitLab hacks for all stages of the DevOps Platform",[7],"michael-friedrich",[9],"Michael Friedrich","It's been ten years since the first commit to GitLab, so we are sharing our ten favorite GitLab hacks to help you get the most out of our DevOps Platform. These are tips for all stages of the development lifecycle, so roll up your sleeves and let's get started.\n\n## Manage faster with quick actions\n\nYou might have adopted keyboard shortcuts for faster navigation and workflows already - if not, check out the GitLab documentation for [platform specific shortcuts](https://docs.gitlab.com/user/shortcuts/). The knowledge of pressing `r` to land in the reply to comment in text form can be combined with other quick actions, including:\n\n```shell\n/assign_reviewer @ \u003Csearch username>\n\n/label ~ \u003Csearch label>\n/label ~enhancement ~workflow::indev\n\n/due Oct 8\n\n/rebase\n\n/approve\n\n/merge\n```\n\nQuick actions are also helpful if you have to manage many issues, merge requests and epics at the same time. There are specific actions which allow you to duplicate existing issues, as one example.\n\nTake a deeper dive into [Quick Actions](/blog/improve-your-gitlab-productivity-with-these-10-tips/).\n\n## Plan instructions with templates\n\nDon’t fall into the trap of back-and-forth with empty issue descriptions that leave out details your development teams need to reproduce the error in the best way possible.\n\nGitLab provides the possibility to use so-called [description templates](https://docs.gitlab.com/user/project/description_templates/) in issues and merge requests. Next to providing a structured template with headings, you can also add [task lists](https://docs.gitlab.com/user/markdown/#task-lists) which can later be ticked off by the assignee. Basically everything is possible and is supported in GitLab-flavored markdown and HTML.\n\nIn addition to that, you can combine the static description templates with quick actions. This allows you to automatically set labels, assignees, define due dates, and more to level up your productivity with GitLab.\n\n```xml\n\u003C!--\nThis is a comment, it will not be rendered by the Markdown engine. You can use it to provide instructions how to fill in the template.\n-->\n\n### Summary\n\n\u003C!-- Summarize the bug encountered concisely. -->\n\n### Steps to reproduce\n\n\u003C!-- Describe how one can reproduce the issue - this is very important. -->\n\n### Output of checks\n\n\u003C!-- If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com -->\n\n#### Results of GitLab environment info\n\n\u003C!--  Input any relevant GitLab environment information if needed. -->\n\n\u003Cdetails>\n\u003Csummary>Expand for output related to app info\u003C/summary>\n\n\u003Cpre>\n\n(Paste the version details of your app here)\n\n\u003C/pre>\n\u003C/details>\n\n### Possible fixes\n\n\u003C!-- If you can, link to the line of code and suggest actions. →\n\n## Maintainer tasks\n\n- [ ] Problem reproduced\n- [ ] Weight added\n- [ ] Fix in test\n- [ ] Docs update needed\n\n/label ~\"type::bug\"\n```\n\nWhen you manage different types of templates, you can pass along the name of the template in the `issuable_template` parameter, for example `https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal%20%23%20lean`.\n\nAt GitLab, we use description and merge request templates in many ways: [GitLab the project](https://gitlab.com/gitlab-org/gitlab/-/tree/master/.gitlab/issue_templates), [GitLab Corporate Marketing team](https://gitlab.com/gitlab-com/marketing/corporate_marketing/corporate-marketing/-/tree/master/.gitlab/issue_templates), [GitLab team member onboarding](https://gitlab.com/gitlab-com/people-group/people-operations/employment-templates/-/tree/master/.gitlab/issue_templates) and [GitLab product team](https://gitlab.com/gitlab-com/Product/-/tree/main/.gitlab/issue_templates) are just a few examples.\n\n## Create with confidence\n\nWhen reading GitLab issues and merge requests, you may see the abbreviation `MWPS` which means `Merge When Pipeline Succeeds`. This is an efficient way to merge the MRs when the pipeline passes all jobs and stages - you can even combine this workflow with [automatically closing issues](https://docs.gitlab.com/user/project/issues/managing_issues/#closing-issues-automatically) with keywords from the MR.\n\n`Merge When Pipeline Succeeds` also works on the CLI with the `git` command and [push options](https://docs.gitlab.com/user/project/push_options/). That way you can create a merge request from a local Git branch, and set it to merge when the pipeline succeeds.\n\n```shell\n# mwps BRANCHNAME\nalias mwps='git push -u origin -o merge_request.create -o merge_request.target=main -o merge_request.merge_when_pipeline_succeeds'\n```\n\nCheckout [this ZSH alias example](https://gitlab.com/sytses/dotfiles/-/blob/745ef9725a859dd759059f6ce283e2a8132c9b00/git/aliases.zsh#L24) in our CEO [Sid Sijbrandij](/company/team/#sytses)’s dotfiles repository. There are more push options available, and even more Git CLI tips in [our tools & tips handbook](https://handbook.gitlab.com/handbook/tools-and-tips/#terminal). One last tip: Delete all local branches where the remote branch was deleted, for example after merging a MR.\n\n```shell\n# Delete all remote tracking Git branches where the upstream branch has been deleted\nalias git_prune=\"git fetch --prune && git branch -vv | grep 'origin/.*: gone]' | awk '{print \\$1}' | xargs git branch -d\"\n```\n\nYou are not bound to your local CLI environment; take it to the cloud with [Gitpod](/blog/teams-gitpod-integration-gitlab-speed-up-development/) and either work in VS Code or the pod terminal.\n\n## Verify your CI/CD pipeline\n\nRemember the old workflow of committing a change to `.gitlab-ci.yml` just to see if it was valid, or if the job template really inherits all the attributes? This has gotten a whole lot easier with our new [pipeline editor](https://docs.gitlab.com/ci/pipeline_editor/). Navigate into the `CI/CD` menu and start building CI/CD pipelines right away.\n\nBut the editor is more than just another YAML editor. You’ll get live linting, allowing you to know if there is a missing dash for array lists or a wrong keyword in use before you commit. You can also preview jobs and stages or asynchronous dependencies with `needs` to make your pipelines more efficient.\n\nThe pipeline editor also uses uses the `/ci/lint` API endpoint, and fetches the merged YAML configuration I described earlier in [this blog post about jq and CI/CD linting](/blog/devops-workflows-json-format-jq-ci-cd-lint/). That way you can quickly verify that job templates with [extends](https://docs.gitlab.com/ci/yaml/#extends) and [!reference tags](https://docs.gitlab.com/ci/yaml/yaml_optimization/#reference-tags) work in the way you designed them. It also allows you to unfold included files, and possible job overrides (for example changing the stage of an [included SAST security template](https://docs.gitlab.com/user/application_security/sast/#overriding-sast-jobs)).\n\nLet’s try a quick example – create a new project and new file called `server.c` with the following content:\n\n```text\n#include \u003Cstdio.h>\n#include \u003Cstring.h>\n#include \u003Csys/mman.h>\n#include \u003Csys/stat.h>\n#include \u003Cunistd.h>\n\nint main(void) {\n    size_t pagesize = getpagesize();\n    char * region = mmap(\n        (void*) (pagesize * (1 \u003C\u003C 20)),\n        pagesize,\n        PROT_READ|PROT_WRITE|PROT_EXEC,\n        MAP_ANON|MAP_PRIVATE, 0, 0);\n\n    strcpy(region, \"Hello GitLab SAST!\");\n    printf(\"Contents of region: %s\\n\", region);\n\n    FILE *fp;\n    fp = fopen(\"devops.platform\", \"r\");\n    fprintf(fp, \"10 years of GitLab 🦊 🥳\");\n    fclose(fp);\n    chmod(\"devops.platform\", S_IRWXU|S_IRWXG|S_IRWXO);\n\n    return 0;\n}\n```\n\nOpen the CI/CD pipeline editor and add the following configuration, with an extra `secure` stage assigned to the `semgrep-sast` job for SAST and the C code.\n\n```yaml\nstages:\n    - build\n    - secure\n    - test\n    - deploy\n\ninclude:\n    - template: Security/SAST.gitlab-ci.yml\n\nsemgrep-sast:\n    stage: secure\n\n```\n\nInspect the `Merged YAML tab` to see the fully compiled CI/CD configuration. You can commit the changes and check the found vulnerabilities too as an async practice :). The examples are available in [this project](https://gitlab.com/gitlab-da/playground/sast-10y-example).\n\n![CI/CD Pipeline editor - Merged YAML](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_pipeline_editor_view_merged_yaml.png)\nVerify the stage attribute for the job by opening the `view merged YAML` tab in the CI/CD pipeline editor.\n\n\n## Package your applications\n\nThe [package registry](https://docs.gitlab.com/user/packages/) possibilities are huge and there are more languages and package managers to come. Describing why Terraform, Helm, and containers (for infrastructure) and Maven, npm, NuGet, PyPI, Composer, Conan, Debian, Go and Ruby Gems (for applications) are so awesome would take too long, but it's clear there are plenty of choices.\n\nOne of my favourite workflows is to use existing CI/CD templates to publish container images in the GitLab container registry. This makes continuous delivery much more efficient, such as when deploying the application into your Kubernetes cluster or AWS instances.\n\n```yaml\ninclude:\n  - template: 'Docker.gitlab-ci.yml'\n\n```\n\nIn addition to including the CI/CD template, you can also override the job attributes and define a specific stage and manual non-blocking rules.\n\n```yaml\nstages:\n  - build\n  - docker-build\n  - test\n\ninclude:\n  - template: 'Docker.gitlab-ci.yml'\n\n# Change Docker build to manual non-blocking\ndocker-build:\n  stage: docker-build\n  rules:\n    - if: '$CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH'\n      when: manual\n      allow_failure: true\n\n```\n\nFor celebrating #10YearsOfGitLab, we have created a [C++ example](https://gitlab.com/gitlab-da/cicd-tanuki-cpp) with an Easter egg on time calculations. This project also uses a Docker builder image to showcase a more efficient pipeline. Our recommendation is to learn using the templates in a test repository, and then create a dedicated group/project for managing all required container images. You can think of builder images which include the compiler tool chain, or specific scripts to run end-to-end tests, etc.\n\n## Secure your secrets\n\nIt is easy to leak a secret by making choices that uncomplicate a unit test by running it directly with the production database. The secret persists in git history, and someone with bad intentions gains access to private data, or finds ways to exploit your supply chain even further.\n\nTo help prevent that, include the CI/CD template for secret detection.\n\n```yaml\nstages:\n    - test\n\ninclude:\n  - template: Security/Secret-Detection.gitlab-ci.yml\n\n```\n\nA known way to leak secrets is committing the `.env` file which stores settings and secrets in the repository. Try the following snippet by adding a new file `.env` and create a merge request.\n\n```shell\nexport AWS_KEY=\"AKIA1318109798ABCDEF\"\n```\n\nInspect the reports JSON to see the raw reports structure. GitLab Ultimate provides an MR integration, a security dashboard overview, and more features to take immediate action. The example can be found in [this project](https://gitlab.com/gitlab-da/playground/secret-scanning-10y-example).\n\n![Secrets Scanning in MR](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_secrets_scanning.png)\nMR detail view with detected AWS secret from security scanning\n\n\n## Release and continuously deliver (CD)\n\nGitLab’s release stage provides many [features](https://handbook.gitlab.com/handbook/product/categories/features/#release), including [canary deployments](https://docs.gitlab.com/user/project/canary_deployments/) and [GitLab pages](https://docs.gitlab.com/user/project/pages/). There are also infrastructure deployments with Terraform and cloud native (protected) [environments](https://docs.gitlab.com/ci/environments/).\n\nWhile working on a CI/CD pipeline efficiency workshop, I got enthusiastic about [parent-child pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#parent-child-pipelines) allowing non-blocking child pipelines into production, with micro services in Kubernetes as one example.\n\nLet’s try it! Create a new project, and add 2 child pipeline configuration files: `child-deploy-staging.yml` and `child-deploy-prod.yml`. The naming is important as the files will be referenced in the main `.gitlab-ci.yml` configuration file later. The jobs in the child pipelines will sleep for 60 seconds to simulate a deployment.\n\nchild-deploy-staging.yml:\n\n```yaml\ndeploy-staging:\n    stage: deploy\n    script:\n        - echo \"Deploying microservices to staging\" && sleep 60\n\n```\n\nchild-deploy-prod.yml\n\n```yaml\ndeploy-prod:\n    stage: deploy\n    script:\n        - echo \"Deploying microservices to prod\" && sleep 60\n\nmonitor-prod:\n    stage: deploy\n    script:\n        - echo \"Monitoring production SLOs\" && sleep 60\n\n```\n\nNow edit the `.gitlab-ci.yml` configuration file and create a build-test-deploy stage workflow.\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nbuild:\n  stage: build\n  script: echo \"Build\"\n\ntest:\n  stage: test\n  script: echo \"Test\"\n\ndeploy-staging-trigger:\n  stage: deploy\n  trigger:\n    include: child-deploy-staging.yml\n  #rules:\n  #  - if: $CI_MERGE_REQUEST_ID\n\ndeploy-prod-trigger:\n  stage: deploy\n  trigger:\n    include: child-deploy-prod.yml\n    #strategy: depend\n  #rules:\n  #  - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n\n```\n\nCommit the changes and inspect the CI/CD pipelines.\n\n![Parent-child Pipelines](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_parent_child_pipelines.png)\nView parent-child pipelines in GitLab\n\n\n`strategy: depends` allows you to make the child pipelines blocking again, and the parent child pipeline waits again. Try uncommenting this for the prod job, and verify that by inspecting the pipeline view. [Rules](https://docs.gitlab.com/ci/yaml/#rules) allow refining the scope when jobs are being run, such as when staging child pipelines that should only be run in merge requests and the prod child pipeline only gets triggered when on the default main branch. The full example can be found in [this project](https://gitlab.com/gitlab-da/playground/parent-child-pipeline-10y-example).\n\nTip: You can use [resource_groups](/blog/introducing-resource-groups/) to limit production deployments from running concurrent child pipelines.\n\n## Configure your infrastructure\n\nTerraform allows you to describe, plan and apply the provisioning of infrastructure resources. The workflow requires a state file to be stored over steps, where the [managed state in GitLab](https://docs.gitlab.com/user/infrastructure/iac/terraform_state/) as an HTTP backend is a great help, together with predefined container images and CI/CD templates to make [Infrastructure as code](https://docs.gitlab.com/user/infrastructure/iac/) as smooth as possible.\n\nYou can customize the template, or copy the CI/CD configuration into .gitlab-ci.yml and modify the steps by yourself. Let’s try a quick example with only an AWS account and an IAM user key pair. Configure them as CI/CD variables in `Settings > CI/CD > Variables`: `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.\n\nNext, create the `backend.tf` file and specify the http backend and AWS module dependency.\n\n```terraform\nterraform {\n  backend \"http\" {\n  }\n\n  required_providers {\n    aws = {\n      source = \"hashicorp/aws\"\n      version = \"~> 3.0\"\n    }\n  }\n}\n```\n\nCreate `provider.tf` to specify the AWS region.\n\n```terraform\nprovider \"aws\" {\n  region = \"us-east-1\"\n}\n```\n\nThe `main.tf` describes the S3 bucket resources.\n\n```terraform\nresource \"aws_s3_bucket_public_access_block\" \"publicaccess\" {\n  bucket = aws_s3_bucket.demobucket.id\n  block_public_acls = false\n  block_public_policy = false\n}\n\nresource \"aws_s3_bucket\" \"demobucket\" {\n  bucket = \"terraformdemobucket\"\n  acl = \"private\"\n}\n```\n\nTip: You can verify the configuration locally on your CLI by commenting out the HTTP backend above.\n\nFor GitLab CI/CD, open the pipeline editor and use the following configuration: (Note that it is important to specify the `TF_ROOT` and `TF_ADDRESS` variables since you can [manage multiple Terraform state files](https://docs.gitlab.com/user/infrastructure/iac/terraform_state/#configure-the-backend)).\n\n```yaml\nvariables:\n  TF_ROOT: ${CI_PROJECT_DIR}\n  TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/${CI_PROJECT_NAME}\n\ninclude:\n    - template: Terraform.latest.gitlab-ci.yml\n\nstages:\n  - init\n  - validate\n  - build\n  - deploy\n  - cleanup\n\ndestroy:\n    stage: cleanup\n    extends: .terraform:destroy\n    when: manual\n    allow_failure: true\n\n```\n\nCommit the configuration and inspect the pipeline jobs.\n\n![Terraform pipeline AWS S3 bucket](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_terraform_state_cicd_pipeline_aws_s3_bucket.png)\nAWS S3 bucket provisioned with Terraform in GitLab CI/CD\n\n\nThe `destroy` job is not created in the template and therefore explicitly added as a manual job. It is recommended to review the opinionated Terraform CI/CD template and copy the jobs into your own configuration to allow for further modifications or style adjustments.  The full example is located in [this project](https://gitlab.com/gitlab-da/playground/terraform-aws-state-10y-example).\n\n![GitLab managed Terraform states](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_terraform_state_cicd_overview.png)\nView the Terraform states in GitLab\n\n\nHat tipping to our Package stage - you can manage and publish [Terraform modules in the registry](https://docs.gitlab.com/user/packages/terraform_module_registry/) too, using all of the DevOps Platform advantages. And hot off the press, the [GitLab Kubernetes Operator is generally available](/blog/open-shift-ga/).\n\n## Monitor GitLab and dive into Prometheus\n\nPrometheus is a monitoring solution which collects metrics from `/metrics` HTTP endpoints made available by applications, as well as so-called exporters to serve services and host information in the specified metrics format. One example is CI/CD pipeline insights to analyse bottlenecks and [make your pipelines more efficient](https://docs.gitlab.com/ci/pipelines/pipeline_efficiency/). The [GitLab CI Pipeline Exporter project](https://github.com/mvisonneau/gitlab-ci-pipelines-exporter/tree/main/examples/quickstart) has a great quick start in under 5 minutes, bringing up demo setup with Docker-compose, Prometheus and Grafana. From there, it is not far into your production monitoring environment, and monitoring more of GitLab.\n\n![GitLab CI Exporter](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_ci_pipeline_exporter_prometheus.png)\nExample dashboard for the GitLab CI Pipeline Exporter\n\n\nThe Prometheus Exporter uses the [Go client libraries](https://prometheus.io/docs/instrumenting/writing_exporters/). They can be used to write your own exporter, or instrument your application code to expose `/metrics`. When deployed, you can use Prometheus again to monitor the performance of your applications in Kubernetes, as one example. Find more monitoring ideas in my talk “[From Monitoring to Observability: Left Shift your SLOs](https://docs.google.com/presentation/d/1LPb-HPMgbc8_l98VjMEo5d0uYlnNnAtJSURngZPWDdE/edit)”.\n\n## Protect\n\nYou can enable security features in GitLab by including the CI/CD templates one by one. A more easy way is to enable [Auto DevOps](https://docs.gitlab.com/topics/autodevops/) and use the default best practices for [security scans](https://docs.gitlab.com/user/application_security/#security-scanning-with-auto-devops). This includes [container scanning](https://docs.gitlab.com/topics/autodevops/stages/#auto-container-scanning) ensuring that application deployments are not vulnerable on the container OS level.\n\nLet’s try a quick example with a potentially vulnerable image, and the Docker template tip from the Package stage above. Create a new `Dockerfile` in a new project:\n\n```yaml\nFROM debian:10.0\n```\n\nOpen the pipeline editor and add the following CI/CD configuration:\n\n```yaml\n# 1. Automatically build the Docker image\n# 2. Run container scanning. https://docs.gitlab.com/user/application_security/container_scanning/\n# 3. Inspect `Security & Compliance > Security Dashboard`\n\n# For demo purposes, scan the latest tagged image from 'main'\nvariables:\n    DOCKER_IMAGE: $CI_REGISTRY_IMAGE:latest\n\ninclude:\n    - template: Docker.gitlab-ci.yml\n    - template: Security/Container-Scanning.gitlab-ci.yml\n\n```\n\nThe full example is located in [this project](https://gitlab.com/gitlab-da/playground/container-scanning-10y-example).\n\nTip: Learn more about [scanning container images in a deployed Kubernetes cluster](https://docs.gitlab.com/user/application_security/container_scanning/) to stay even more safe.\n\n![Container Scanning Vulnerability Report](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_container_scanning_vulnerability_report.png)\nView the container scanning vulnerability report\n\n\n## What’s next?\n\nWe have tried to find a great “hack” for each stage of the DevOps lifecycle. There are more hacks and hidden gems inside GitLab - share yours and be ready to explore more stages of the DevOps Platform.\n\nCover image by [Alin Andersen](https://unsplash.com/photos/diUGN5N5Rrs) on [Unsplash](https://unsplash.com)\n","devsecops",{"slug":13,"featured":14,"template":15},"top-10-gitlab-hacks",false,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"Get the most out of the GitLab DevOps Platform with our ten best tips for enhanced productivity.",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667482/Blog/Hero%20Images/cover-image-unsplash.jpg","2021-10-19",[22,23,24],"tutorial","DevOps","workflow","yml",null,{},true,"/en-us/blog/top-10-gitlab-hacks","seo:\n  title: Top ten GitLab hacks for all stages of the DevOps Platform\n  description: >-\n    Get the most out of the GitLab DevOps Platform with our ten best tips for\n    enhanced productivity.\n  ogTitle: Top ten GitLab hacks for all stages of the DevOps Platform\n  ogDescription: >-\n    Get the most out of the GitLab DevOps Platform with our ten best tips for\n    enhanced productivity.\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667482/Blog/Hero%20Images/cover-image-unsplash.jpg\n  ogUrl: https://about.gitlab.com/blog/top-10-gitlab-hacks\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/top-10-gitlab-hacks\ncontent:\n  title: Top ten GitLab hacks for all stages of the DevOps Platform\n  description: >-\n    Get the most out of the GitLab DevOps Platform with our ten best tips for\n    enhanced productivity.\n  authors:\n    - Michael Friedrich\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667482/Blog/Hero%20Images/cover-image-unsplash.jpg\n  date: '2021-10-19'\n  body: >\n    It's been ten years since the first commit to GitLab, so we are sharing our\n    ten favorite GitLab hacks to help you get the most out of our DevOps\n    Platform. These are tips for all stages of the development lifecycle, so\n    roll up your sleeves and let's get started.\n\n\n    ## Manage faster with quick actions\n\n\n    You might have adopted keyboard shortcuts for faster navigation and\n    workflows already - if not, check out the GitLab documentation for [platform\n    specific shortcuts](https://docs.gitlab.com/user/shortcuts/). The\n    knowledge of pressing `r` to land in the reply to comment in text form can\n    be combined with other quick actions, including:\n\n\n    ```shell\n\n    /assign_reviewer @ \u003Csearch username>\n\n\n    /label ~ \u003Csearch label>\n\n    /label ~enhancement ~workflow::indev\n\n\n    /due Oct 8\n\n\n    /rebase\n\n\n    /approve\n\n\n    /merge\n\n    ```\n\n\n    Quick actions are also helpful if you have to manage many issues, merge\n    requests and epics at the same time. There are specific actions which allow\n    you to duplicate existing issues, as one example.\n\n\n    Take a deeper dive into [Quick\n    Actions](/blog/improve-your-gitlab-productivity-with-these-10-tips/).\n\n\n    ## Plan instructions with templates\n\n\n    Don’t fall into the trap of back-and-forth with empty issue descriptions\n    that leave out details your development teams need to reproduce the error in\n    the best way possible.\n\n\n    GitLab provides the possibility to use so-called [description\n    templates](https://docs.gitlab.com/user/project/description_templates/)\n    in issues and merge requests. Next to providing a structured template with\n    headings, you can also add [task\n    lists](https://docs.gitlab.com/user/markdown/#task-lists) which can\n    later be ticked off by the assignee. Basically everything is possible and is\n    supported in GitLab-flavored markdown and HTML.\n\n\n    In addition to that, you can combine the static description templates with\n    quick actions. This allows you to automatically set labels, assignees,\n    define due dates, and more to level up your productivity with GitLab.\n\n\n    ```xml\n\n    \u003C!--\n\n    This is a comment, it will not be rendered by the Markdown engine. You can\n    use it to provide instructions how to fill in the template.\n\n    -->\n\n\n    ### Summary\n\n\n    \u003C!-- Summarize the bug encountered concisely. -->\n\n\n    ### Steps to reproduce\n\n\n    \u003C!-- Describe how one can reproduce the issue - this is very important. -->\n\n\n    ### Output of checks\n\n\n    \u003C!-- If you are reporting a bug on GitLab.com, write: This bug happens on\n    GitLab.com -->\n\n\n    #### Results of GitLab environment info\n\n\n    \u003C!--  Input any relevant GitLab environment information if needed. -->\n\n\n    \u003Cdetails>\n\n    \u003Csummary>Expand for output related to app info\u003C/summary>\n\n\n    \u003Cpre>\n\n\n    (Paste the version details of your app here)\n\n\n    \u003C/pre>\n\n    \u003C/details>\n\n\n    ### Possible fixes\n\n\n    \u003C!-- If you can, link to the line of code and suggest actions. →\n\n\n    ## Maintainer tasks\n\n\n    - [ ] Problem reproduced\n\n    - [ ] Weight added\n\n    - [ ] Fix in test\n\n    - [ ] Docs update needed\n\n\n    /label ~\"type::bug\"\n\n    ```\n\n\n    When you manage different types of templates, you can pass along the name of\n    the template in the `issuable_template` parameter, for example\n    `https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal%20%23%20lean`.\n\n\n    At GitLab, we use description and merge request templates in many ways:\n    [GitLab the\n    project](https://gitlab.com/gitlab-org/gitlab/-/tree/master/.gitlab/issue_templates),\n    [GitLab Corporate Marketing\n    team](https://gitlab.com/gitlab-com/marketing/corporate_marketing/corporate-marketing/-/tree/master/.gitlab/issue_templates),\n    [GitLab team member\n    onboarding](https://gitlab.com/gitlab-com/people-group/people-operations/employment-templates/-/tree/master/.gitlab/issue_templates)\n    and [GitLab product\n    team](https://gitlab.com/gitlab-com/Product/-/tree/main/.gitlab/issue_templates)\n    are just a few examples.\n\n\n    ## Create with confidence\n\n\n    When reading GitLab issues and merge requests, you may see the abbreviation\n    `MWPS` which means `Merge When Pipeline Succeeds`. This is an efficient way\n    to merge the MRs when the pipeline passes all jobs and stages - you can even\n    combine this workflow with [automatically closing\n    issues](https://docs.gitlab.com/user/project/issues/managing_issues/#closing-issues-automatically)\n    with keywords from the MR.\n\n\n    `Merge When Pipeline Succeeds` also works on the CLI with the `git` command\n    and [push\n    options](https://docs.gitlab.com/user/project/push_options/). That\n    way you can create a merge request from a local Git branch, and set it to\n    merge when the pipeline succeeds.\n\n\n    ```shell\n\n    # mwps BRANCHNAME\n\n    alias mwps='git push -u origin -o merge_request.create -o\n    merge_request.target=main -o merge_request.merge_when_pipeline_succeeds'\n\n    ```\n\n\n    Checkout [this ZSH alias\n    example](https://gitlab.com/sytses/dotfiles/-/blob/745ef9725a859dd759059f6ce283e2a8132c9b00/git/aliases.zsh#L24)\n    in our CEO [Sid Sijbrandij](/company/team/#sytses)’s dotfiles repository.\n    There are more push options available, and even more Git CLI tips in [our\n    tools & tips\n    handbook](https://handbook.gitlab.com/handbook/tools-and-tips/#terminal).\n    One last tip: Delete all local branches where the remote branch was deleted,\n    for example after merging a MR.\n\n\n    ```shell\n\n    # Delete all remote tracking Git branches where the upstream branch has been\n    deleted\n\n    alias git_prune=\"git fetch --prune && git branch -vv | grep 'origin/.*:\n    gone]' | awk '{print \\$1}' | xargs git branch -d\"\n\n    ```\n\n\n    You are not bound to your local CLI environment; take it to the cloud with\n    [Gitpod](/blog/teams-gitpod-integration-gitlab-speed-up-development/) and\n    either work in VS Code or the pod terminal.\n\n\n    ## Verify your CI/CD pipeline\n\n\n    Remember the old workflow of committing a change to `.gitlab-ci.yml` just to\n    see if it was valid, or if the job template really inherits all the\n    attributes? This has gotten a whole lot easier with our new [pipeline\n    editor](https://docs.gitlab.com/ci/pipeline_editor/). Navigate into the\n    `CI/CD` menu and start building CI/CD pipelines right away.\n\n\n    But the editor is more than just another YAML editor. You’ll get live\n    linting, allowing you to know if there is a missing dash for array lists or\n    a wrong keyword in use before you commit. You can also preview jobs and\n    stages or asynchronous dependencies with `needs` to make your pipelines more\n    efficient.\n\n\n    The pipeline editor also uses uses the `/ci/lint` API endpoint, and fetches\n    the merged YAML configuration I described earlier in [this blog post about\n    jq and CI/CD linting](/blog/devops-workflows-json-format-jq-ci-cd-lint/).\n    That way you can quickly verify that job templates with\n    [extends](https://docs.gitlab.com/ci/yaml/#extends) and [!reference\n    tags](https://docs.gitlab.com/ci/yaml/yaml_optimization/#reference-tags)\n    work in the way you designed them. It also allows you to unfold included\n    files, and possible job overrides (for example changing the stage of an\n    [included SAST security\n    template](https://docs.gitlab.com/user/application_security/sast/#overriding-sast-jobs)).\n\n\n    Let’s try a quick example – create a new project and new file called\n    `server.c` with the following content:\n\n\n    ```text\n\n    #include \u003Cstdio.h>\n\n    #include \u003Cstring.h>\n\n    #include \u003Csys/mman.h>\n\n    #include \u003Csys/stat.h>\n\n    #include \u003Cunistd.h>\n\n\n    int main(void) {\n        size_t pagesize = getpagesize();\n        char * region = mmap(\n            (void*) (pagesize * (1 \u003C\u003C 20)),\n            pagesize,\n            PROT_READ|PROT_WRITE|PROT_EXEC,\n            MAP_ANON|MAP_PRIVATE, 0, 0);\n\n        strcpy(region, \"Hello GitLab SAST!\");\n        printf(\"Contents of region: %s\\n\", region);\n\n        FILE *fp;\n        fp = fopen(\"devops.platform\", \"r\");\n        fprintf(fp, \"10 years of GitLab 🦊 🥳\");\n        fclose(fp);\n        chmod(\"devops.platform\", S_IRWXU|S_IRWXG|S_IRWXO);\n\n        return 0;\n    }\n\n    ```\n\n\n    Open the CI/CD pipeline editor and add the following configuration, with an\n    extra `secure` stage assigned to the `semgrep-sast` job for SAST and the C\n    code.\n\n\n    ```yaml\n\n    stages:\n        - build\n        - secure\n        - test\n        - deploy\n\n    include:\n        - template: Security/SAST.gitlab-ci.yml\n\n    semgrep-sast:\n        stage: secure\n\n    ```\n\n\n    Inspect the `Merged YAML tab` to see the fully compiled CI/CD configuration.\n    You can commit the changes and check the found vulnerabilities too as an\n    async practice :). The examples are available in [this\n    project](https://gitlab.com/gitlab-da/playground/sast-10y-example).\n\n\n    ![CI/CD Pipeline editor - Merged\n    YAML](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_pipeline_editor_view_merged_yaml.png)\n\n    Verify the stage attribute for the job by opening the `view merged YAML` tab\n    in the CI/CD pipeline editor.\n\n\n\n    ## Package your applications\n\n\n    The [package registry](https://docs.gitlab.com/user/packages/)\n    possibilities are huge and there are more languages and package managers to\n    come. Describing why Terraform, Helm, and containers (for infrastructure)\n    and Maven, npm, NuGet, PyPI, Composer, Conan, Debian, Go and Ruby Gems (for\n    applications) are so awesome would take too long, but it's clear there are\n    plenty of choices.\n\n\n    One of my favourite workflows is to use existing CI/CD templates to publish\n    container images in the GitLab container registry. This makes continuous\n    delivery much more efficient, such as when deploying the application into\n    your Kubernetes cluster or AWS instances.\n\n\n    ```yaml\n\n    include:\n      - template: 'Docker.gitlab-ci.yml'\n\n    ```\n\n\n    In addition to including the CI/CD template, you can also override the job\n    attributes and define a specific stage and manual non-blocking rules.\n\n\n    ```yaml\n\n    stages:\n      - build\n      - docker-build\n      - test\n\n    include:\n      - template: 'Docker.gitlab-ci.yml'\n\n    # Change Docker build to manual non-blocking\n\n    docker-build:\n      stage: docker-build\n      rules:\n        - if: '$CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH'\n          when: manual\n          allow_failure: true\n\n    ```\n\n\n    For celebrating #10YearsOfGitLab, we have created a [C++\n    example](https://gitlab.com/gitlab-da/cicd-tanuki-cpp) with an Easter egg on\n    time calculations. This project also uses a Docker builder image to showcase\n    a more efficient pipeline. Our recommendation is to learn using the\n    templates in a test repository, and then create a dedicated group/project\n    for managing all required container images. You can think of builder images\n    which include the compiler tool chain, or specific scripts to run end-to-end\n    tests, etc.\n\n\n    ## Secure your secrets\n\n\n    It is easy to leak a secret by making choices that uncomplicate a unit test\n    by running it directly with the production database. The secret persists in\n    git history, and someone with bad intentions gains access to private data,\n    or finds ways to exploit your supply chain even further.\n\n\n    To help prevent that, include the CI/CD template for secret detection.\n\n\n    ```yaml\n\n    stages:\n        - test\n\n    include:\n      - template: Security/Secret-Detection.gitlab-ci.yml\n\n    ```\n\n\n    A known way to leak secrets is committing the `.env` file which stores\n    settings and secrets in the repository. Try the following snippet by adding\n    a new file `.env` and create a merge request.\n\n\n    ```shell\n\n    export AWS_KEY=\"AKIA1318109798ABCDEF\"\n\n    ```\n\n\n    Inspect the reports JSON to see the raw reports structure. GitLab Ultimate\n    provides an MR integration, a security dashboard overview, and more features\n    to take immediate action. The example can be found in [this\n    project](https://gitlab.com/gitlab-da/playground/secret-scanning-10y-example).\n\n\n    ![Secrets Scanning in\n    MR](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_secrets_scanning.png)\n\n    MR detail view with detected AWS secret from security scanning\n\n\n\n    ## Release and continuously deliver (CD)\n\n\n    GitLab’s release stage provides many\n    [features](https://handbook.gitlab.com/handbook/product/categories/features/#release),\n    including [canary\n    deployments](https://docs.gitlab.com/user/project/canary_deployments/)\n    and [GitLab pages](https://docs.gitlab.com/user/project/pages/). There\n    are also infrastructure deployments with Terraform and cloud native\n    (protected) [environments](https://docs.gitlab.com/ci/environments/).\n\n\n    While working on a CI/CD pipeline efficiency workshop, I got enthusiastic\n    about [parent-child\n    pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#parent-child-pipelines)\n    allowing non-blocking child pipelines into production, with micro services\n    in Kubernetes as one example.\n\n\n    Let’s try it! Create a new project, and add 2 child pipeline configuration\n    files: `child-deploy-staging.yml` and `child-deploy-prod.yml`. The naming is\n    important as the files will be referenced in the main `.gitlab-ci.yml`\n    configuration file later. The jobs in the child pipelines will sleep for 60\n    seconds to simulate a deployment.\n\n\n    child-deploy-staging.yml:\n\n\n    ```yaml\n\n    deploy-staging:\n        stage: deploy\n        script:\n            - echo \"Deploying microservices to staging\" && sleep 60\n\n    ```\n\n\n    child-deploy-prod.yml\n\n\n    ```yaml\n\n    deploy-prod:\n        stage: deploy\n        script:\n            - echo \"Deploying microservices to prod\" && sleep 60\n\n    monitor-prod:\n        stage: deploy\n        script:\n            - echo \"Monitoring production SLOs\" && sleep 60\n\n    ```\n\n\n    Now edit the `.gitlab-ci.yml` configuration file and create a\n    build-test-deploy stage workflow.\n\n\n    ```yaml\n\n    stages:\n      - build\n      - test\n      - deploy\n\n    build:\n      stage: build\n      script: echo \"Build\"\n\n    test:\n      stage: test\n      script: echo \"Test\"\n\n    deploy-staging-trigger:\n      stage: deploy\n      trigger:\n        include: child-deploy-staging.yml\n      #rules:\n      #  - if: $CI_MERGE_REQUEST_ID\n\n    deploy-prod-trigger:\n      stage: deploy\n      trigger:\n        include: child-deploy-prod.yml\n        #strategy: depend\n      #rules:\n      #  - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n\n    ```\n\n\n    Commit the changes and inspect the CI/CD pipelines.\n\n\n    ![Parent-child\n    Pipelines](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_parent_child_pipelines.png)\n\n    View parent-child pipelines in GitLab\n\n\n\n    `strategy: depends` allows you to make the child pipelines blocking again,\n    and the parent child pipeline waits again. Try uncommenting this for the\n    prod job, and verify that by inspecting the pipeline view.\n    [Rules](https://docs.gitlab.com/ci/yaml/#rules) allow refining the scope\n    when jobs are being run, such as when staging child pipelines that should\n    only be run in merge requests and the prod child pipeline only gets\n    triggered when on the default main branch. The full example can be found in\n    [this\n    project](https://gitlab.com/gitlab-da/playground/parent-child-pipeline-10y-example).\n\n\n    Tip: You can use [resource_groups](/blog/introducing-resource-groups/) to\n    limit production deployments from running concurrent child pipelines.\n\n\n    ## Configure your infrastructure\n\n\n    Terraform allows you to describe, plan and apply the provisioning of\n    infrastructure resources. The workflow requires a state file to be stored\n    over steps, where the [managed state in\n    GitLab](https://docs.gitlab.com/user/infrastructure/iac/terraform_state/)\n    as an HTTP backend is a great help, together with predefined container\n    images and CI/CD templates to make [Infrastructure as\n    code](https://docs.gitlab.com/user/infrastructure/iac/) as smooth as\n    possible.\n\n\n    You can customize the template, or copy the CI/CD configuration into\n    .gitlab-ci.yml and modify the steps by yourself. Let’s try a quick example\n    with only an AWS account and an IAM user key pair. Configure them as CI/CD\n    variables in `Settings > CI/CD > Variables`: `AWS_ACCESS_KEY_ID` and\n    `AWS_SECRET_ACCESS_KEY`.\n\n\n    Next, create the `backend.tf` file and specify the http backend and AWS\n    module dependency.\n\n\n    ```terraform\n\n    terraform {\n      backend \"http\" {\n      }\n\n      required_providers {\n        aws = {\n          source = \"hashicorp/aws\"\n          version = \"~> 3.0\"\n        }\n      }\n    }\n\n    ```\n\n\n    Create `provider.tf` to specify the AWS region.\n\n\n    ```terraform\n\n    provider \"aws\" {\n      region = \"us-east-1\"\n    }\n\n    ```\n\n\n    The `main.tf` describes the S3 bucket resources.\n\n\n    ```terraform\n\n    resource \"aws_s3_bucket_public_access_block\" \"publicaccess\" {\n      bucket = aws_s3_bucket.demobucket.id\n      block_public_acls = false\n      block_public_policy = false\n    }\n\n\n    resource \"aws_s3_bucket\" \"demobucket\" {\n      bucket = \"terraformdemobucket\"\n      acl = \"private\"\n    }\n\n    ```\n\n\n    Tip: You can verify the configuration locally on your CLI by commenting out\n    the HTTP backend above.\n\n\n    For GitLab CI/CD, open the pipeline editor and use the following\n    configuration: (Note that it is important to specify the `TF_ROOT` and\n    `TF_ADDRESS` variables since you can [manage multiple Terraform state\n    files](https://docs.gitlab.com/user/infrastructure/iac/terraform_state/#configure-the-backend)).\n\n\n    ```yaml\n\n    variables:\n      TF_ROOT: ${CI_PROJECT_DIR}\n      TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/${CI_PROJECT_NAME}\n\n    include:\n        - template: Terraform.latest.gitlab-ci.yml\n\n    stages:\n      - init\n      - validate\n      - build\n      - deploy\n      - cleanup\n\n    destroy:\n        stage: cleanup\n        extends: .terraform:destroy\n        when: manual\n        allow_failure: true\n\n    ```\n\n\n    Commit the configuration and inspect the pipeline jobs.\n\n\n    ![Terraform pipeline AWS S3\n    bucket](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_terraform_state_cicd_pipeline_aws_s3_bucket.png)\n\n    AWS S3 bucket provisioned with Terraform in GitLab CI/CD\n\n\n\n    The `destroy` job is not created in the template and therefore explicitly\n    added as a manual job. It is recommended to review the opinionated Terraform\n    CI/CD template and copy the jobs into your own configuration to allow for\n    further modifications or style adjustments.  The full example is located in\n    [this\n    project](https://gitlab.com/gitlab-da/playground/terraform-aws-state-10y-example).\n\n\n    ![GitLab managed Terraform\n    states](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_terraform_state_cicd_overview.png)\n\n    View the Terraform states in GitLab\n\n\n\n    Hat tipping to our Package stage - you can manage and publish [Terraform\n    modules in the\n    registry](https://docs.gitlab.com/user/packages/terraform_module_registry/)\n    too, using all of the DevOps Platform advantages. And hot off the press, the\n    [GitLab Kubernetes Operator is generally available](/blog/open-shift-ga/).\n\n\n    ## Monitor GitLab and dive into Prometheus\n\n\n    Prometheus is a monitoring solution which collects metrics from `/metrics`\n    HTTP endpoints made available by applications, as well as so-called\n    exporters to serve services and host information in the specified metrics\n    format. One example is CI/CD pipeline insights to analyse bottlenecks and\n    [make your pipelines more\n    efficient](https://docs.gitlab.com/ci/pipelines/pipeline_efficiency/).\n    The [GitLab CI Pipeline Exporter\n    project](https://github.com/mvisonneau/gitlab-ci-pipelines-exporter/tree/main/examples/quickstart)\n    has a great quick start in under 5 minutes, bringing up demo setup with\n    Docker-compose, Prometheus and Grafana. From there, it is not far into your\n    production monitoring environment, and monitoring more of GitLab.\n\n\n    ![GitLab CI\n    Exporter](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_ci_pipeline_exporter_prometheus.png)\n\n    Example dashboard for the GitLab CI Pipeline Exporter\n\n\n\n    The Prometheus Exporter uses the [Go client\n    libraries](https://prometheus.io/docs/instrumenting/writing_exporters/).\n    They can be used to write your own exporter, or instrument your application\n    code to expose `/metrics`. When deployed, you can use Prometheus again to\n    monitor the performance of your applications in Kubernetes, as one example.\n    Find more monitoring ideas in my talk “[From Monitoring to Observability:\n    Left Shift your\n    SLOs](https://docs.google.com/presentation/d/1LPb-HPMgbc8_l98VjMEo5d0uYlnNnAtJSURngZPWDdE/edit)”.\n\n\n    ## Protect\n\n\n    You can enable security features in GitLab by including the CI/CD templates\n    one by one. A more easy way is to enable [Auto\n    DevOps](https://docs.gitlab.com/topics/autodevops/) and use the default\n    best practices for [security\n    scans](https://docs.gitlab.com/user/application_security/#security-scanning-with-auto-devops).\n    This includes [container\n    scanning](https://docs.gitlab.com/topics/autodevops/stages/#auto-container-scanning)\n    ensuring that application deployments are not vulnerable on the container OS\n    level.\n\n\n    Let’s try a quick example with a potentially vulnerable image, and the\n    Docker template tip from the Package stage above. Create a new `Dockerfile`\n    in a new project:\n\n\n    ```yaml\n\n    FROM debian:10.0\n\n    ```\n\n\n    Open the pipeline editor and add the following CI/CD configuration:\n\n\n    ```yaml\n\n    # 1. Automatically build the Docker image\n\n    # 2. Run container scanning.\n    https://docs.gitlab.com/user/application_security/container_scanning/\n\n    # 3. Inspect `Security & Compliance > Security Dashboard`\n\n\n    # For demo purposes, scan the latest tagged image from 'main'\n\n    variables:\n        DOCKER_IMAGE: $CI_REGISTRY_IMAGE:latest\n\n    include:\n        - template: Docker.gitlab-ci.yml\n        - template: Security/Container-Scanning.gitlab-ci.yml\n\n    ```\n\n\n    The full example is located in [this\n    project](https://gitlab.com/gitlab-da/playground/container-scanning-10y-example).\n\n\n    Tip: Learn more about [scanning container images in a deployed Kubernetes\n    cluster](https://docs.gitlab.com/user/application_security/container_scanning/)\n    to stay even more safe.\n\n\n    ![Container Scanning Vulnerability\n    Report](https://about.gitlab.com/images/blogimages/top-10-gitlab-hacks/gitlab_10y_container_scanning_vulnerability_report.png)\n\n    View the container scanning vulnerability report\n\n\n\n    ## What’s next?\n\n\n    We have tried to find a great “hack” for each stage of the DevOps lifecycle.\n    There are more hacks and hidden gems inside GitLab - share yours and be\n    ready to explore more stages of the DevOps Platform.\n\n\n    Cover image by [Alin Andersen](https://unsplash.com/photos/diUGN5N5Rrs) on\n    [Unsplash](https://unsplash.com)\n  category: devsecops\n  tags:\n    - tutorial\n    - DevOps\n    - workflow\nconfig:\n  slug: top-10-gitlab-hacks\n  featured: false\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":14,"ogImage":19,"ogUrl":32,"ogSiteName":33,"ogType":34,"canonicalUrls":32},"https://about.gitlab.com/blog/top-10-gitlab-hacks","https://about.gitlab.com","article","en-us/blog/top-10-gitlab-hacks",[22,37,24],"devops",[22,23,24],"dcppbHFKlYlna9gjP0YIKWBqXhI6dANYBx94kjpmCvU",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":371,"minimal":402,"duo":421,"switchNav":430,"pricingDeployment":441},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/","gitlab logo","header",{"text":48,"config":49},"Get free trial",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"Talk to sales",{"href":55,"dataGaName":56,"dataGaLocation":46},"/sales/","sales",{"text":58,"config":59},"Sign in",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,185,190,292,352],{"text":64,"config":65,"cards":67},"Platform",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"The intelligent orchestration platform for DevSecOps",{"text":71,"config":72},"Explore our Platform",{"href":73,"dataGaName":66,"dataGaLocation":46},"/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":78,"config":79},"Meet GitLab Duo",{"href":80,"dataGaName":81,"dataGaLocation":46},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":86,"config":87},"Learn more",{"href":88,"dataGaName":89,"dataGaLocation":46},"/why-gitlab/","why gitlab",{"text":91,"left":28,"config":92,"link":94,"lists":98,"footer":167},"Product",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":46},"/solutions/",[99,123,146],{"title":100,"description":101,"link":102,"items":107},"Automation","CI/CD and automation to accelerate deployment",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,115,119],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":46,"dataGaName":109},"/solutions/continuous-integration/",{"text":75,"config":113},{"href":80,"dataGaLocation":46,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"Source Code Management",{"href":118,"dataGaLocation":46,"dataGaName":116},"/solutions/source-code-management/",{"text":120,"config":121},"Automated Software Delivery",{"href":105,"dataGaLocation":46,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Security","Deliver code faster without compromising security",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":46,"icon":130},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Application Security Testing",{"href":128,"dataGaName":135,"dataGaLocation":46},"Application security testing",{"text":137,"config":138},"Software Supply Chain Security",{"href":139,"dataGaLocation":46,"dataGaName":140},"/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software Compliance",{"href":144,"dataGaName":145,"dataGaLocation":46},"/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"Measurement",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":46},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[154,158,162],{"text":155,"config":156},"Visibility & Measurement",{"href":151,"dataGaLocation":46,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Value Stream Management",{"href":161,"dataGaLocation":46,"dataGaName":159},"/solutions/value-stream-management/",{"text":163,"config":164},"Analytics & Insights",{"href":165,"dataGaLocation":46,"dataGaName":166},"/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab for",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":46,"dataGaName":174},"/enterprise/","enterprise",{"text":176,"config":177},"Small Business",{"href":178,"dataGaLocation":46,"dataGaName":179},"/small-business/","small business",{"text":181,"config":182},"Public Sector",{"href":183,"dataGaLocation":46,"dataGaName":184},"/solutions/public-sector/","public sector",{"text":186,"config":187},"Pricing",{"href":188,"dataGaName":189,"dataGaLocation":46,"dataNavLevelOne":189},"/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":283},"Resources",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"View all resources",{"href":197,"dataGaName":193,"dataGaLocation":46},"/resources/",[199,232,255],{"title":200,"items":201},"Getting started",[202,207,212,217,222,227],{"text":203,"config":204},"Install",{"href":205,"dataGaName":206,"dataGaLocation":46},"/install/","install",{"text":208,"config":209},"Quick start guides",{"href":210,"dataGaName":211,"dataGaLocation":46},"/get-started/","quick setup checklists",{"text":213,"config":214},"Learn",{"href":215,"dataGaLocation":46,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Product documentation",{"href":220,"dataGaName":221,"dataGaLocation":46},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best practice videos",{"href":225,"dataGaName":226,"dataGaLocation":46},"/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrations",{"href":230,"dataGaName":231,"dataGaLocation":46},"/integrations/","integrations",{"title":233,"items":234},"Discover",[235,240,245,250],{"text":236,"config":237},"Customer success stories",{"href":238,"dataGaName":239,"dataGaLocation":46},"/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":46},"/blog/","blog",{"text":246,"config":247},"The Source",{"href":248,"dataGaName":249,"dataGaLocation":46},"/the-source/","the source",{"text":251,"config":252},"Remote",{"href":253,"dataGaName":254,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":256,"items":257},"Connect",[258,263,268,273,278],{"text":259,"config":260},"GitLab Services",{"href":261,"dataGaName":262,"dataGaLocation":46},"/services/","services",{"text":264,"config":265},"Community",{"href":266,"dataGaName":267,"dataGaLocation":46},"/community/","community",{"text":269,"config":270},"Forum",{"href":271,"dataGaName":272,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":274,"config":275},"Events",{"href":276,"dataGaName":277,"dataGaLocation":46},"/events/","events",{"text":279,"config":280},"Partners",{"href":281,"dataGaName":282,"dataGaLocation":46},"/partners/","partners",{"textColor":284,"title":285,"text":286,"link":287},"#000","What’s new in GitLab","Stay updated with our latest features and improvements.",{"text":288,"config":289},"Read the latest",{"href":290,"dataGaName":291,"dataGaLocation":46},"/releases/whats-new/","whats new",{"text":293,"config":294,"lists":296},"Company",{"dataNavLevelOne":295},"company",[297],{"items":298},[299,304,310,312,317,322,327,332,337,342,347],{"text":300,"config":301},"About",{"href":302,"dataGaName":303,"dataGaLocation":46},"/company/","about",{"text":305,"config":306,"footerGa":309},"Jobs",{"href":307,"dataGaName":308,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":308},{"text":274,"config":311},{"href":276,"dataGaName":277,"dataGaLocation":46},{"text":313,"config":314},"Leadership",{"href":315,"dataGaName":316,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":318,"config":319},"Team",{"href":320,"dataGaName":321,"dataGaLocation":46},"/company/team/","team",{"text":323,"config":324},"Handbook",{"href":325,"dataGaName":326,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"Investor relations",{"href":330,"dataGaName":331,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"Trust Center",{"href":335,"dataGaName":336,"dataGaLocation":46},"/security/","trust center",{"text":338,"config":339},"AI Transparency Center",{"href":340,"dataGaName":341,"dataGaLocation":46},"/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"Newsletter",{"href":345,"dataGaName":346,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"Press",{"href":350,"dataGaName":351,"dataGaLocation":46},"/press/","press",{"text":353,"config":354,"lists":355},"Contact us",{"dataNavLevelOne":295},[356],{"items":357},[358,361,366],{"text":53,"config":359},{"href":55,"dataGaName":360,"dataGaLocation":46},"talk to sales",{"text":362,"config":363},"Support portal",{"href":364,"dataGaName":365,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":367,"config":368},"Customer portal",{"href":369,"dataGaName":370,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"Close",{"text":374,"link":375},"To search repositories and projects, login to",{"text":376,"config":377},"gitlab.com",{"href":60,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"Suggestions",[383,385,389,391,395,399],{"text":75,"config":384},{"href":80,"dataGaName":75,"dataGaLocation":379},{"text":386,"config":387},"Code Suggestions (AI)",{"href":388,"dataGaName":386,"dataGaLocation":379},"/solutions/code-suggestions/",{"text":109,"config":390},{"href":111,"dataGaName":109,"dataGaLocation":379},{"text":392,"config":393},"GitLab on AWS",{"href":394,"dataGaName":392,"dataGaLocation":379},"/partners/technology-partners/aws/",{"text":396,"config":397},"GitLab on Google Cloud",{"href":398,"dataGaName":396,"dataGaLocation":379},"/partners/technology-partners/google-cloud-platform/",{"text":400,"config":401},"Why GitLab?",{"href":88,"dataGaName":400,"dataGaLocation":379},{"freeTrial":403,"mobileIcon":408,"desktopIcon":413,"secondaryButton":416},{"text":404,"config":405},"Start free trial",{"href":406,"dataGaName":51,"dataGaLocation":407},"https://gitlab.com/-/trials/new/","nav",{"altText":409,"config":410},"Gitlab Icon",{"src":411,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":409,"config":414},{"src":415,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":417,"config":418},"Get Started",{"href":419,"dataGaName":420,"dataGaLocation":407},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":422,"mobileIcon":426,"desktopIcon":428},{"text":423,"config":424},"Learn more about GitLab Duo",{"href":80,"dataGaName":425,"dataGaLocation":407},"gitlab duo",{"altText":409,"config":427},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":429},{"src":415,"dataGaName":412,"dataGaLocation":407},{"button":431,"mobileIcon":436,"desktopIcon":438},{"text":432,"config":433},"/switch",{"href":434,"dataGaName":435,"dataGaLocation":407},"#contact","switch",{"altText":409,"config":437},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":439},{"src":440,"dataGaName":412,"dataGaLocation":407},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":442,"mobileIcon":447,"desktopIcon":449},{"text":443,"config":444},"Back to pricing",{"href":188,"dataGaName":445,"dataGaLocation":407,"icon":446},"back to pricing","GoBack",{"altText":409,"config":448},{"src":411,"dataGaName":412,"dataGaLocation":407},{"altText":409,"config":450},{"src":415,"dataGaName":412,"dataGaLocation":407},{"title":452,"button":453,"config":458},"See how agentic AI transforms software delivery",{"text":454,"config":455},"Watch GitLab Transcend now",{"href":456,"dataGaName":457,"dataGaLocation":46},"/events/transcend/virtual/","transcend event",{"layout":459,"icon":460,"disabled":28},"release","AiStar",{"data":462},{"text":463,"source":464,"edit":470,"contribute":475,"config":480,"items":485,"minimal":689},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":465,"config":466},"View page source",{"href":467,"dataGaName":468,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":471,"config":472},"Edit this page",{"href":473,"dataGaName":474,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":476,"config":477},"Please contribute",{"href":478,"dataGaName":479,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":481,"facebook":482,"youtube":483,"linkedin":484},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[486,533,584,628,655],{"title":186,"links":487,"subMenu":502},[488,492,497],{"text":489,"config":490},"View plans",{"href":188,"dataGaName":491,"dataGaLocation":469},"view plans",{"text":493,"config":494},"Why Premium?",{"href":495,"dataGaName":496,"dataGaLocation":469},"/pricing/premium/","why premium",{"text":498,"config":499},"Why Ultimate?",{"href":500,"dataGaName":501,"dataGaLocation":469},"/pricing/ultimate/","why ultimate",[503],{"title":504,"links":505},"Contact Us",[506,509,511,513,518,523,528],{"text":507,"config":508},"Contact sales",{"href":55,"dataGaName":56,"dataGaLocation":469},{"text":362,"config":510},{"href":364,"dataGaName":365,"dataGaLocation":469},{"text":367,"config":512},{"href":369,"dataGaName":370,"dataGaLocation":469},{"text":514,"config":515},"Status",{"href":516,"dataGaName":517,"dataGaLocation":469},"https://status.gitlab.com/","status",{"text":519,"config":520},"Terms of use",{"href":521,"dataGaName":522,"dataGaLocation":469},"/terms/","terms of use",{"text":524,"config":525},"Privacy statement",{"href":526,"dataGaName":527,"dataGaLocation":469},"/privacy/","privacy statement",{"text":529,"config":530},"Cookie preferences",{"dataGaName":531,"dataGaLocation":469,"id":532,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"title":91,"links":534,"subMenu":543},[535,539],{"text":536,"config":537},"DevSecOps platform",{"href":73,"dataGaName":538,"dataGaLocation":469},"devsecops platform",{"text":540,"config":541},"AI-Assisted Development",{"href":80,"dataGaName":542,"dataGaLocation":469},"ai-assisted development",[544],{"title":545,"links":546},"Topics",[547,552,557,560,565,569,574,579],{"text":548,"config":549},"CICD",{"href":550,"dataGaName":551,"dataGaLocation":469},"/topics/ci-cd/","cicd",{"text":553,"config":554},"GitOps",{"href":555,"dataGaName":556,"dataGaLocation":469},"/topics/gitops/","gitops",{"text":23,"config":558},{"href":559,"dataGaName":37,"dataGaLocation":469},"/topics/devops/",{"text":561,"config":562},"Version Control",{"href":563,"dataGaName":564,"dataGaLocation":469},"/topics/version-control/","version control",{"text":566,"config":567},"DevSecOps",{"href":568,"dataGaName":11,"dataGaLocation":469},"/topics/devsecops/",{"text":570,"config":571},"Cloud Native",{"href":572,"dataGaName":573,"dataGaLocation":469},"/topics/cloud-native/","cloud native",{"text":575,"config":576},"AI for Coding",{"href":577,"dataGaName":578,"dataGaLocation":469},"/topics/devops/ai-for-coding/","ai for coding",{"text":580,"config":581},"Agentic AI",{"href":582,"dataGaName":583,"dataGaLocation":469},"/topics/agentic-ai/","agentic ai",{"title":585,"links":586},"Solutions",[587,589,591,596,600,603,607,610,612,615,618,623],{"text":133,"config":588},{"href":128,"dataGaName":133,"dataGaLocation":469},{"text":122,"config":590},{"href":105,"dataGaName":106,"dataGaLocation":469},{"text":592,"config":593},"Agile development",{"href":594,"dataGaName":595,"dataGaLocation":469},"/solutions/agile-delivery/","agile delivery",{"text":597,"config":598},"SCM",{"href":118,"dataGaName":599,"dataGaLocation":469},"source code management",{"text":548,"config":601},{"href":111,"dataGaName":602,"dataGaLocation":469},"continuous integration & delivery",{"text":604,"config":605},"Value stream management",{"href":161,"dataGaName":606,"dataGaLocation":469},"value stream management",{"text":553,"config":608},{"href":609,"dataGaName":556,"dataGaLocation":469},"/solutions/gitops/",{"text":171,"config":611},{"href":173,"dataGaName":174,"dataGaLocation":469},{"text":613,"config":614},"Small business",{"href":178,"dataGaName":179,"dataGaLocation":469},{"text":616,"config":617},"Public sector",{"href":183,"dataGaName":184,"dataGaLocation":469},{"text":619,"config":620},"Education",{"href":621,"dataGaName":622,"dataGaLocation":469},"/solutions/education/","education",{"text":624,"config":625},"Financial services",{"href":626,"dataGaName":627,"dataGaLocation":469},"/solutions/finance/","financial services",{"title":191,"links":629},[630,632,634,636,639,641,643,645,647,649,651,653],{"text":203,"config":631},{"href":205,"dataGaName":206,"dataGaLocation":469},{"text":208,"config":633},{"href":210,"dataGaName":211,"dataGaLocation":469},{"text":213,"config":635},{"href":215,"dataGaName":216,"dataGaLocation":469},{"text":218,"config":637},{"href":220,"dataGaName":638,"dataGaLocation":469},"docs",{"text":241,"config":640},{"href":243,"dataGaName":244,"dataGaLocation":469},{"text":236,"config":642},{"href":238,"dataGaName":239,"dataGaLocation":469},{"text":251,"config":644},{"href":253,"dataGaName":254,"dataGaLocation":469},{"text":259,"config":646},{"href":261,"dataGaName":262,"dataGaLocation":469},{"text":264,"config":648},{"href":266,"dataGaName":267,"dataGaLocation":469},{"text":269,"config":650},{"href":271,"dataGaName":272,"dataGaLocation":469},{"text":274,"config":652},{"href":276,"dataGaName":277,"dataGaLocation":469},{"text":279,"config":654},{"href":281,"dataGaName":282,"dataGaLocation":469},{"title":293,"links":656},[657,659,661,663,665,667,669,673,678,680,682,684],{"text":300,"config":658},{"href":302,"dataGaName":295,"dataGaLocation":469},{"text":305,"config":660},{"href":307,"dataGaName":308,"dataGaLocation":469},{"text":313,"config":662},{"href":315,"dataGaName":316,"dataGaLocation":469},{"text":318,"config":664},{"href":320,"dataGaName":321,"dataGaLocation":469},{"text":323,"config":666},{"href":325,"dataGaName":326,"dataGaLocation":469},{"text":328,"config":668},{"href":330,"dataGaName":331,"dataGaLocation":469},{"text":670,"config":671},"Sustainability",{"href":672,"dataGaName":670,"dataGaLocation":469},"/sustainability/",{"text":674,"config":675},"Diversity, inclusion and belonging (DIB)",{"href":676,"dataGaName":677,"dataGaLocation":469},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":679},{"href":335,"dataGaName":336,"dataGaLocation":469},{"text":343,"config":681},{"href":345,"dataGaName":346,"dataGaLocation":469},{"text":348,"config":683},{"href":350,"dataGaName":351,"dataGaLocation":469},{"text":685,"config":686},"Modern Slavery Transparency Statement",{"href":687,"dataGaName":688,"dataGaLocation":469},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":690},[691,694,697],{"text":692,"config":693},"Terms",{"href":521,"dataGaName":522,"dataGaLocation":469},{"text":695,"config":696},"Cookies",{"dataGaName":531,"dataGaLocation":469,"id":532,"isOneTrustButton":28},{"text":698,"config":699},"Privacy",{"href":526,"dataGaName":527,"dataGaLocation":469},[701],{"id":702,"title":9,"body":26,"config":703,"content":705,"description":26,"extension":25,"meta":709,"navigation":28,"path":710,"seo":711,"stem":712,"__hash__":713},"blogAuthors/en-us/blog/authors/michael-friedrich.yml",{"template":704},"BlogAuthor",{"name":9,"config":706},{"headshot":707,"ctfId":708},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659879/Blog/Author%20Headshots/dnsmichi-headshot.jpg","dnsmichi",{},"/en-us/blog/authors/michael-friedrich",{},"en-us/blog/authors/michael-friedrich","lJ-nfRIhdG49Arfrxdn1Vv4UppwD51BB13S3HwIswt4",[715,728,743],{"content":716,"config":726},{"title":717,"description":718,"authors":719,"heroImage":721,"date":722,"body":723,"category":11,"tags":724},"Teaching software development the easy way using GitLab","Learn how University of Washington lecturer Stephen G. Dame uses GitLab for Education to manage student assignments, distribute course materials, and provide inline code feedback at scale.\n",[720],"Rod Burns","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659537/Blog/Hero%20Images/display-article-image-0679-1800x945-fy26.png","2026-04-29","For instructors teaching software development, one of the biggest logistical challenges is assignment distribution and feedback at scale. How do you give large groups of students access to course materials, keep solution code private, and still deliver meaningful, contextual feedback without lots of administrative overhead?\n\nThe **[GitLab for Education program](https://about.gitlab.com/solutions/education/)** provides qualifying institutions with free access to **GitLab Ultimate**, enabling instructors to build professional-grade workflows that mirror real-world software development environments. In this article, you'll learn how Stephen G. Dame, a lecturer in the Computing and Software Systems department at the University of Washington, Bothell, uses simple workflows in GitLab to manage everything from course materials to student feedback across multiple classes.\n\n## From aerospace to academia: Bringing GitLab to the classroom\n\nDame came to academia with years of experience as a chief software engineer at Boeing Commercial Airplanes, where GitLab was used for aerospace projects. As an adjunct professor, he became an early advocate for GitLab within the university, joining the GitLab for Education program to access the full feature set needed to run structured, scalable course workflows.\n\n> **\"GitLab provides the greatest way to organize multiple classes, student assignments, lectures, and code samples through the use of Groups and Subgroups, which I found to be unique to GitLab compared to other repository platforms.\"**\n>\n> - Stephen G. Dame, University of Washington, Bothell\n\n## Set up groups: Build the right structure before writing a line of code\n\nThe foundation of an effective GitLab-based course is a well-planned group hierarchy. GitLab's **[Groups and Subgroups](https://docs.gitlab.com/tutorials/manage_user/#create-the-organization-parent-group-and-subgroups)** allow instructors to model the natural structure of a university department institution, course, and role with precise, inheritable permissions at every level.\n\nDame's structure places the university at the root (`UWTeaching`), with each course occupying its own subgroup (e.g. `css430`). Within each course sit repositories for `lecture-materials` and `code`, alongside dedicated Subgroups for `students` and `graders`. Instructor materials remain private, while student and grader subgroups are configured with controlled permissions so that assignment briefs and solutions are visible only to the right people.\n\n![Screenshot of GitLab group hierarchy — institution, course subgroup, and per-student subgroups](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777463673/dpxfnitv76pdmvcqtgag.png)\n\nPermissions cascade downward through the hierarchy via **Manage > Members**, allowing Dame to add students to a course's `students` subgroup with `Reporter` access and an expiration date tied to the end of the academic quarter. Students can clone and pull from assignment repositories but cannot push — keeping solution code firmly under instructor control.\n\nStudents are guided to set up SSH keys across all their working environments (local machines, cloud shells, virtual machines) so they can clone repositories and receive weekly updates via `git pull`. They copy relevant code into their own private repositories to manage their own version history.\n\n**Tip for large classes:** For larger cohorts, adding students by hand is impractical. GitLab's REST API lets you automate subgroup creation and membership from a list of usernames. Below is a sample Python script that handles this:\n\n```python\n    import gitlab\n    from datetime import datetime\n\n    # Connect to your GitLab instance\n    gl = gitlab.Gitlab('https://gitlab.com', private_token='YOUR_PRIVATE_TOKEN')\n\n    # Target parent group ID (e.g., the ID for \"css430 > students\")\n    parent_group_id = 12345678\n\n    # Set expiration: typically the beginning of the next month after quarter end\n    expiry_date = '2025-01-01'\n\n    # List of collected student usernames\n    student_list = ['alice_css430', 'bob_css430', 'carol_css430', 'dave_css430', 'eve_css430']\n\n    for username in student_list:\n        try:\n            # 1. Create a personal subgroup for the student\n            subgroup = gl.groups.create({\n                'name': username,\n                'path': username,\n                'parent_id': parent_group_id,\n                'visibility': 'private'\n            })\n\n            # 2. Add student to the new subgroup with Expiration\n            user = gl.users.list(username=username)[0]\n            subgroup.members.create({\n                'user_id': user.id,\n                'access_level': gitlab.const.REPORTER_ACCESS,\n                'expires_at': expiry_date\n            })\n            print(f\"Success: Subgroup created and student added for {username}\")\n        except Exception as e:\n            print(f\"Error processing {username}: {e}\")\n```\nThere is also an [open source project that automates class management](https://gitlab.com/edu-docs/class-management-automation) published by GitLab that provides additional tooling for this workflow.\n## Give feedback where the work actually lives\n\nOnce the structure is in place, the feedback workflow is where GitLab's value becomes most apparent to students. Dame asks students to submit assignments by opening a **[merge request](https://docs.gitlab.com/user/project/merge_requests/)** in their repository. This gives instructors an immediate, clean diff of everything the student has written.\n![A GitLab merge request showing inline code comment function for an instructor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777467468/icclzyglbkwlvfysggbi.png)\nInstructors can click any line of code and leave an **inline comment** — not just flagging what is wrong, but explaining why, and pointing to what to look at next. Students receive this feedback in direct context with their code, which is far more actionable than a comment at the bottom of a submitted document.\n\n## Join GitLab for Education\n\nSetting up your first GitLab assignment takes some initial effort, but once the structure is in place it largely runs itself. The real payoff goes beyond organization: Students graduate having worked daily in an environment that mirrors professional software development, building habits around [version control](https://about.gitlab.com/topics/version-control/) and [code review](https://docs.gitlab.com/development/code_review/) rather than learning them as abstract concepts.\n\nIf you are just getting started, keep it simple. Begin with a single course group, one assignment template, and a basic pipeline. The structure will grow naturally alongside your confidence with the platform.\n\nMake sure to **[sign up for GitLab for Education](https://about.gitlab.com/solutions/education/join/)** so that you and your students can access all top-tier features, including unlimited reviewers on merge requests, additional compute minutes, and expanded storage.\n\n> [Apply to the GitLab for Education program today](https://about.gitlab.com/solutions/education/join/).",[622,725],"open source",{"featured":14,"template":15,"slug":727},"teaching-software-development-the-easy-way-using-gitlab",{"content":729,"config":741},{"description":730,"authors":731,"heroImage":733,"date":734,"title":735,"body":736,"category":11,"tags":737},"AI-generated code is 34% of development work. Discover how to balance productivity gains with quality, reliability, and security.",[732],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1767982271/e9ogyosmuummq7j65zqg.png","2026-01-08","AI is reshaping DevSecOps: Attend GitLab Transcend to see what’s next","AI promises a step change in innovation velocity, but most software teams are hitting a wall. According to our latest [Global DevSecOps Report](https://about.gitlab.com/developer-survey/), AI-generated code now accounts for 34% of all development work. Yet 70% of DevSecOps professionals report that AI is making compliance management more difficult, and 76% say agentic AI will create unprecedented security challenges.\n\nThis is the AI paradox: AI accelerates coding, but software delivery slows down as teams struggle to test, secure, and deploy all that code.\n\n## Productivity gains meet workflow bottlenecks\nThe problem isn't AI itself. It's how software gets built today. The traditional DevSecOps lifecycle contains hundreds of small tasks that developers must navigate manually: updating tickets, running tests, requesting reviews, waiting for approvals, fixing merge conflicts, addressing security findings. These tasks drain an average of seven hours per week from every team member, according to our research.\n\nDevelopment teams are producing code faster than ever, but that code still crawls through fragmented toolchains, manual handoffs, and disconnected processes. In fact, 60% of DevSecOps teams use more than five tools for software development overall, and 49% use more than five AI tools. This fragmentation creates collaboration barriers, with 94% of DevSecOps professionals experiencing factors that limit collaboration in the software development lifecycle.\n\nThe answer isn't more tools. It's intelligent orchestration that brings software teams and their AI agents together across projects and release cycles, with enterprise-grade security, governance, and compliance built in.\n\n## Seeking deeper human-AI partnerships\nDevSecOps professionals don't want AI to take over — they want reliable partnerships. The vast majority (82%) say using agentic AI would increase their job satisfaction, and 43% envision an ideal future with a 50/50 split between human and AI contributions. They're ready to trust AI with 37% of their daily tasks without human review, particularly for documentation, test writing, and code reviews.\n\nWhat we heard resoundingly from DevSecOps professionals is that AI won't replace them; rather, it will fundamentally reshape their roles. 83% of DevSecOps professionals believe AI will significantly change their work within five years, and notably, 76% think this will create more engineering jobs, not fewer. As coding becomes easier with AI, engineers who can architect systems, ensure quality, and apply business context will be in high demand.\n\nCritically, 88% agree there are essential human qualities that AI will never fully replace, including creativity, innovation, collaboration, and strategic vision.\n\nSo how can organizations bridge the gap between AI’s promise and the reality of fragmented workflows?\n\n## Join us at GitLab Transcend: Explore how to drive real value with agentic AI\nOn February 10, 2026, GitLab will be hosting Transcend, where we'll reveal how intelligent orchestration transforms AI-powered software development. You'll get a first look at GitLab's upcoming product roadmap and learn how teams are solving real-world challenges by modernizing development workflows with AI.\n\nOrganizations winning in this new era balance AI adoption with security, compliance, and platform consolidation. AI offers genuine productivity gains when implemented thoughtfully — not by replacing human developers, but by freeing DevSecOps professionals to focus on strategic thinking and creative innovation.\n\n[Register for Transcend today](https://about.gitlab.com/events/transcend/virtual/) to secure your spot and discover how intelligent orchestration can help your software teams stay in flow.",[738,739,740],"AI/ML","DevOps platform","security",{"featured":28,"template":15,"slug":742},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"content":744,"config":755},{"title":745,"description":746,"authors":747,"heroImage":749,"date":750,"body":751,"category":11,"tags":752},"Atlassian ending Data Center as GitLab maintains deployment choice","As Atlassian transitions Data Center customers to cloud-only, GitLab presents a menu of deployment choices that map to business needs.",[748],"Emilio Salvador","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2025-10-07","Change is never easy, especially when it's not your choice. Atlassian's announcement that [all Data Center products will reach end-of-life by March 28, 2029](https://www.atlassian.com/blog/announcements/atlassian-ascend), means thousands of organizations must now reconsider their DevSecOps deployment and infrastructure. But you don't have to settle for deployment options that don't fit your needs. GitLab maintains your freedom to choose — whether you need self-managed for compliance, cloud for convenience, or hybrid for flexibility — all within a single AI-powered DevSecOps platform that respects your requirements.\n\nWhile other vendors force migrations to cloud-only architectures, GitLab remains committed to supporting the deployment choices that match your business needs. Whether you're managing sensitive government data, operating in air-gapped environments, or simply prefer the control of self-managed deployments, we understand that one size doesn't fit all.\n\n## The cloud isn't the answer for everyone\n\nFor the many companies that invested millions of dollars in Data Center deployments, including those that migrated to Data Center [after its Server products were discontinued](https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/), this announcement represents more than a product sunset. It signals a fundamental shift away from customer-centric architecture choices, forcing enterprises into difficult positions: accept a deployment model that doesn't fit their needs, or find a vendor that respects their requirements.\n\nMany of the organizations requiring self-managed deployments represent some of the world's most important organizations: healthcare systems protecting patient data, financial institutions managing trillions in assets, government agencies safeguarding national security, and defense contractors operating in air-gapped environments.\n\nThese organizations don't choose self-managed deployments for convenience; they choose them for compliance, security, and sovereignty requirements that cloud-only architectures simply cannot meet. Organizations operating in closed environments with restricted or no internet access aren't exceptions — they represent a significant portion of enterprise customers across various industries.\n\n![GitLab vs. Atlassian comparison table](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759928476/ynl7wwmkh5xyqhszv46m.jpg)\n\n## The real cost of forced cloud migration goes beyond dollars\n\nWhile cloud-only vendors frame mandatory migrations as \"upgrades,\" organizations face substantial challenges beyond simple financial costs:\n\n* **Lost integration capabilities:** Years of custom integrations with legacy systems, carefully crafted workflows, and enterprise-specific automations become obsolete. Organizations with deep integrations to legacy systems often find cloud migration technically infeasible.\n\n* **Regulatory constraints:** For organizations in regulated industries, cloud migration isn't just complex — it's often not permitted. Data residency requirements, air-gapped environments, and strict regulatory frameworks don't bend to vendor preferences. The absence of single-tenant solutions in many cloud-only approaches creates insurmountable compliance barriers.\n\n* **Productivity impacts:** Cloud-only architectures often require juggling multiple products: separate tools for planning, code management, CI/CD, and documentation. Each tool means another context switch, another integration to maintain, another potential point of failure. GitLab research shows [30% of developers spend at least 50% of their job maintaining and/or integrating their DevSecOps toolchain](https://about.gitlab.com/developer-survey/). Fragmented architectures exacerbate this challenge rather than solving it.\n\n## GitLab offers choice, commitment, and consolidation\n\nEnterprise customers deserve a trustworthy technology partner. That's why we've committed to supporting a range of deployment options — whether you need on-premises for compliance, hybrid for flexibility, or cloud for convenience, the choice remains yours. That commitment continues with [GitLab Duo](https://about.gitlab.com/gitlab-duo-agent-platform/), our AI solution that supports developers at every stage of their workflow.\n\nBut we offer more than just deployment flexibility. While other vendors might force you to cobble together their products into a fragmented toolchain, GitLab provides everything in a **comprehensive AI-native DevSecOps platform**. Source code management, CI/CD, security scanning, Agile planning, and documentation are all managed within a single application and a single vendor relationship.\n\nThis isn't theoretical. When Airbus and [Iron Mountain](https://about.gitlab.com/customers/iron-mountain/) evaluated their existing fragmented toolchains, they consistently identified challenges: poor user experience, missing functionalities like built-in security scanning and review apps, and management complexity from plugin troubleshooting. **These aren't minor challenges; they're major blockers for modern software delivery.**\n\n## Your migration path: Simpler than you think\n\nWe've helped thousands of organizations migrate from other vendors, and we've built the tools and expertise to make your transition smooth:\n\n* **Automated migration tools:** Our [Bitbucket Server importer](https://docs.gitlab.com/user/import/bitbucket_server/) brings over repositories, pull requests, comments, and even Large File Storage (LFS) objects. For Jira, our [built-in importer](https://docs.gitlab.com/user/project/import/jira/) handles issues, descriptions, and labels, with professional services available for complex migrations.\n\n* **Proven at scale:** A 500 GiB repository with 13,000 pull requests, 10,000 branches, and 7,000 tags is likely to [take just 8 hours to migrate](https://docs.gitlab.com/user/import/bitbucket_server/) from Bitbucket to GitLab using parallel processing.\n\n* **Immediate ROI:** A [Forrester Consulting Total Economic Impact™ study commissioned by GitLab](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/) found that investing in GitLab Ultimate confirms these benefits translate to real bottom-line impact, with a three-year 483% ROI, 5x time saved in security related activities, and 25% savings in software toolchain costs.\n\n## Start your journey to a unified DevSecOps platform\n\nForward-thinking organizations aren't waiting for vendor-mandated deadlines. They're evaluating alternatives now, while they have time to migrate thoughtfully to platforms that protect their investments and deliver on promises.\n\nOrganizations invest in self-managed deployments because they need control, compliance, and customization. When vendors deprecate these capabilities, they remove not just features but the fundamental ability to choose environments matching business requirements.\n\nModern DevSecOps platforms should offer complete functionality that respects deployment needs, consolidates toolchains, and accelerates software delivery, without forcing compromises on security or data sovereignty.\n\n[Talk to our sales team](https://about.gitlab.com/sales/) today about your migration options, or explore our [comprehensive migration resources](https://about.gitlab.com/move-to-gitlab-from-atlassian/) to see how thousands of organizations have already made the switch.\n\nYou also can [try GitLab Ultimate with GitLab Duo Enterprise](https://about.gitlab.com/free-trial/devsecops/) for free for 30 days to see what a unified DevSecOps platform can do for your organization.",[573,566,753,754],"product","features",{"featured":28,"template":15,"slug":756},"atlassian-ending-data-center-as-gitlab-maintains-deployment-choice",{"promotions":758},[759,773,784,795],{"id":760,"categories":761,"header":763,"text":764,"button":765,"image":770},"ai-modernization",[762],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":766,"config":767},"Get your AI maturity score",{"href":768,"dataGaName":769,"dataGaLocation":244},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":771},{"src":772},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":774,"categories":775,"header":776,"text":764,"button":777,"image":781},"devops-modernization",[753,11],"Are you just managing tools or shipping innovation?",{"text":778,"config":779},"Get your DevOps maturity score",{"href":780,"dataGaName":769,"dataGaLocation":244},"/assessments/devops-modernization-assessment/",{"config":782},{"src":783},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":785,"categories":786,"header":787,"text":764,"button":788,"image":792},"security-modernization",[740],"Are you trading speed for security?",{"text":789,"config":790},"Get your security maturity score",{"href":791,"dataGaName":769,"dataGaLocation":244},"/assessments/security-modernization-assessment/",{"config":793},{"src":794},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":796,"paths":797,"header":800,"text":801,"button":802,"image":807},"github-azure-migration",[798,799],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":803,"config":804},"See how GitLab compares to GitHub",{"href":805,"dataGaName":806,"dataGaLocation":244},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":808},{"src":783},{"header":810,"blurb":811,"button":812,"secondaryButton":817},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":813,"config":814},"Get your free trial",{"href":815,"dataGaName":51,"dataGaLocation":816},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":507,"config":818},{"href":55,"dataGaName":56,"dataGaLocation":816},1777493608000]