Technical Support: Response Times, Device Configuration, and GitLab Templates for DevSecOps Learners

Welcome to the Practical DevSecOps support hub! Whether you’re setting up a lab environment, waiting for a response from our support team, or looking for a starter GitLab CI/CD template, this guide consolidates the most frequently needed information into one easy‑to‑navigate article. Follow the steps below to avoid common pitfalls, keep your learning momentum, and get the most out of your DevSecOps training.

1. Configuring Your Laptop or Device for Lab Access

Why device configuration matters

Company‑issued laptops often come with corporate firewalls, proxy settings, or endpoint‑security agents that can unintentionally block traffic to the Practical DevSecOps lab platform. When the lab cannot be reached, exercises stall and valuable learning time is lost.

Recommended approach: use a personal device

If you must use a company laptop

1. Check outbound connectivity

   • Verify that ports 80 (HTTP), 443 (HTTPS), and any custom ports listed in your lab instructions are open.

   • Use telnet <lab‑url> 443 or curl -I https://<lab‑url> to confirm reachability.

2. Whitelist the lab domain

   • Request your IT team to add *.practical‑devsecops.com to the firewall’s allowed list.

   • Provide the exact URLs from the lab guide (e.g., lab.practical-devsecops.com, api.practical-devsecops.com).

3. Disable conflicting VPNs or proxy agents

   • Some corporate VPNs route all traffic through a gateway that blocks external lab traffic.

   • Temporarily disconnect from the VPN while working on lab exercises, then reconnect for regular work.

4. Run a quick connectivity test

   # Test HTTPS access to the lab platform
   curl -I https://lab.practical-devsecops.com
   # Expected output: HTTP/2 200 OK
   

   If you receive a timeout or 403/502 error, revisit the firewall whitelist step.

Scenario: Anna, a new student, kept receiving “Unable to connect to the lab” errors on her corporate laptop. After adding lab.practical-devsecops.com to the corporate firewall whitelist and disabling her VPN, the issue resolved within minutes.

2. How Quickly Can You Expect a Response?

Standard response timeline

• Typical turnaround: 3 business days from the time you send an email to trainings@practical-devsecops.com.

• What counts as a business day? Monday through Friday, excluding public holidays observed by our support team.

Tips to accelerate assistance

Example email:

Subject: Lab 5 – GitLab Runner cannot pull Docker image

Hi Support,

I’m using Windows 10 (v22H2) on a personal laptop. When I run `gitlab-runner exec docker` I receive:
  ERROR: Failed to pull image “python:3.9-slim”.

I’ve verified that port 443 is open and can access https://gitlab.com.

Could you advise?

Thanks,  
Mark

Following these guidelines often results in a response within 24–48 hours, even though the official SLA is three business days.

3. Getting Started with a Basic GitLab CI/CD Template

A solid CI/CD pipeline is the backbone of any DevSecOps workflow. GitLab provides a library of ready‑made templates that you can import directly into your project.

Where to find the official templates

• URL: https://docs.gitlab.com/ee/development/cicd/templates.html

• The page lists templates for languages (Python, Node.js, Java), security scanning (SAST, DAST), and deployment strategies.

Minimal “Hello World” pipeline example

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  image: maven:3.8.5-jdk-11
  script:
    - mvn compile

test_job:
  stage: test
  image: maven:3.8.5-jdk-11
  script:
    - mvn test

deploy_job:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Deploy step – replace with your own commands"

How to use it

1. Create a file named .gitlab-ci.yml at the root of your repository.

2. Copy the snippet above into the file.

3. Commit and push to GitLab; the pipeline will automatically trigger.

You can replace the image and script sections with the language or toolset relevant to your lab exercise.

Extending the template for security scanning

Add a SAST job using GitLab’s built‑in scanner:

sast:
  stage: test
  image: docker:stable
  services:
    - docker:dind
  script:
    - echo "Running SAST..."

This addition demonstrates how security testing integrates directly into the CI pipeline—core to DevSecOps practice.

4. Common Questions & Quick Tips

FAQ

• Q: My lab environment still blocks connections after whitelisting the domain.
  A: Verify that your local antivirus or endpoint protection isn’t intercepting HTTPS traffic. Temporarily disable it for troubleshooting.

• Q: Can I expect a faster reply on weekends?
  A: Support operates Monday‑Friday. Weekend queries are queued and addressed on the next business day.

• Q: Do I need to modify the GitLab template for every lab?
  A: Most labs start with the basic template; only replace the script commands with those specified in the lab instructions.

Pro Tips

• Bookmark the GitLab template page for quick reference during labs.

• Create a “support log” in a shared note (e.g., OneNote) to track questions, timestamps, and resolutions—helpful for future cohorts.

• Test connectivity early: Run a simple curl command to the lab URL before diving into complex exercises.

5. Next Steps

1. Configure your device following the checklist in Section 1.

2. Request to a real agent with detailed information as outlined in Section 2.

3. Clone the starter GitLab repository and apply the basic .gitlab-ci.yml template from Section 3.

By preparing your environment ahead of time and using the communication best practices described here, you’ll spend less time troubleshooting and more time mastering DevSecOps concepts. Happy learning!