Mobile App Now Available

Master Interviews
Anywhere, Anytime

Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.

Get it on

Google Play

4.9/5 Rating on Store

Company page Subject page

Uber · CI/CD Pipelines

Uber CI/CD Pipelines interview questions

Practice CI/CD Pipelines questions specifically asked in Uber interviews – ideal for online test preparation, technical rounds and final HR discussions.

Company: UberSubject: CI/CD Pipelines12 questions in this page

Quick overview

Questions

Tagged for this company + subject

Company

Uber

View company-wise questions

Subject

CI/CD Pipelines

Explore topic-wise practice

Uber · CI/CD Pipelines questions (12)

Go through each question and its explanation. Use this page for targeted revision just before your Uber CI/CD Pipelines round.

Back to Uber page•View all CI/CD Pipelines questions

1. Explain Gradle build system including build.gradle syntax, dependency management, tasks, multi-project builds, and performance optimization techniques.

Difficulty: HardType: SubjectiveTopic: Build Tools

Gradle uses Groovy or Kotlin DSL for build configuration. Build.gradle defines project structure: ```groovy plugins { id 'java' id 'org.springframework.boot' version '2.7.0' id 'io.spring.dependency-management' version '1.0.11.RELEASE' } group = 'com.example' version = '1.0.0' sourceCompatibility = '11' repositories { mavenCentral() maven { url 'https://nexus.company.com/repository/maven-public/' credentials { username = System.getenv('NEXUS_USER') password = System.getenv('NEXUS_PASSWORD') } } } dependencies { implementation 'org.springframework.boot:spring-boot-starter-web' implementation 'org.postgresql:postgresql:42.3.1' testImplementation 'org.springframework.boot:spring-boot-starter-test' testImplementation 'org.junit.jupiter:junit-jupiter' } tasks.named('test') { useJUnitPlatform() } ``` Dependency configurations: implementation (compile and runtime, not exposed to consumers), api (exposed to consumers in library projects), compileOnly (compile time only, like Maven provided), runtimeOnly (runtime only), testImplementation, testRuntimeOnly. Dependency constraints and versions: ```groovy dependencies { implementation 'com.google.guava:guava:31.0-jre' implementation 'com.fasterxml.jackson.core:jackson-databind:2.13.0' // Constraint (doesn't add dependency, only sets version if included transitively) constraints { implementation 'org.apache.commons:commons-lang3:3.12.0' } } ``` Dependency resolution strategies: ```groovy configurations.all { resolutionStrategy { // Force specific version force 'com.google.guava:guava:31.0-jre' // Fail on version conflict failOnVersionConflict() // Cache for 24 hours cacheDynamicVersionsFor 24, 'hours' } } ``` Custom tasks: ```groovy task hello { doLast { println 'Hello from Gradle!' } } task copyDocs(type: Copy) { from 'src/docs' into 'build/docs' } task buildDockerImage(type: Exec) { commandLine 'docker', 'build', '-t', "myapp:${version}", '.' } task dist(type: Zip) { from 'build/libs' archiveFileName = "myapp-${version}.zip" } ``` Multi-project builds organize related projects: ``` root-project/ ├── settings.gradle ├── build.gradle ├── app/ │ └── build.gradle ├── library/ │ └── build.gradle └── common/ └── build.gradle ``` Settings.gradle: ```groovy rootProject.name = 'my-application' include 'app', 'library', 'common' ``` Root build.gradle: ```groovy subprojects { apply plugin: 'java' repositories { mavenCentral() } dependencies { testImplementation 'junit:junit:4.13.2' } } ``` App build.gradle: ```groovy dependencies { implementation project(':library') implementation project(':common') } ``` Performance optimization: Gradle daemon (enabled by default, reuses JVM across builds), build cache (caches task outputs): ```groovy buildCache { local { enabled = true } remote(HttpBuildCache) { url = 'https://cache.company.com/' credentials { username = System.getenv('BUILD_CACHE_USER') password = System.getenv('BUILD_CACHE_PASSWORD') } push = true } } ``` Parallel execution: ```bash ./gradlew build --parallel ``` Configuration cache (faster configuration phase): ```bash ./gradlew build --configuration-cache ``` CI/CD integration: ```yaml # GitHub Actions - uses: gradle/gradle-build-action@v2 with: arguments: build cache-read-only: false ``` Publishing artifacts: ```groovy plugins { id 'maven-publish' } publishing { publications { mavenJava(MavenPublication) { from components.java } } repositories { maven { url = version.endsWith('SNAPSHOT') ? 'https://nexus.company.com/repository/maven-snapshots/' : 'https://nexus.company.com/repository/maven-releases/' credentials { username = System.getenv('NEXUS_USER') password = System.getenv('NEXUS_PASSWORD') } } } } ``` Best practices: use Gradle wrapper, enable build cache, use parallel execution, leverage incremental compilation, cache dependencies in CI/CD, use configuration cache for large projects, profile builds (./gradlew build --scan), modularize large projects. Understanding Gradle enables efficient, flexible build automation.

Continue your preparation

For complete preparation, combine this company + subject page with full company-wise practice and subject-wise practice. You can also explore other companies and topics from the links below.

Quick navigation:Uber company page•CI/CD Pipelines subject page•All companies•All subjects

2. Explain npm package management, scripts, versioning, and CI/CD integration. Include npm vs yarn, lock files, and security practices.

Difficulty: MediumType: SubjectiveTopic: Build Tools

npm (Node Package Manager) manages JavaScript dependencies defined in package.json: ```json { "name": "my-app", "version": "1.0.0", "description": "My application", "main": "index.js", "scripts": { "start": "node index.js", "dev": "nodemon index.js", "build": "webpack --mode production", "test": "jest", "lint": "eslint src/", "format": "prettier --write src/" }, "dependencies": { "express": "^4.18.0", "dotenv": "^16.0.0" }, "devDependencies": { "jest": "^28.0.0", "nodemon": "^2.0.0", "eslint": "^8.0.0" }, "engines": { "node": ">=16.0.0", "npm": ">=8.0.0" } } ``` Dependency types: dependencies (production), devDependencies (development only, not installed in production with npm install --production), peerDependencies (required by library but provided by consumer), optionalDependencies (install if possible, failure doesn't stop installation). Version ranges: "^4.18.0" (compatible with 4.x.x, >= 4.18.0 < 5.0.0), "~4.18.0" (patch updates, >= 4.18.0 < 4.19.0), "4.18.0" (exact version), "*" (any version). Caret (^) is default, allows minor and patch updates. Lock files (package-lock.json) ensure reproducible installs by recording exact versions of all dependencies and transitive dependencies: ```json { "name": "my-app", "version": "1.0.0", "lockfileVersion": 2, "requires": true, "packages": { "node_modules/express": { "version": "4.18.2", "resolved": "https://registry.npmjs.org/express/-/express-4.18.2.tgz", "integrity": "sha512-..." } } } ``` Commit lock file to version control. npm commands: npm install (install dependencies from package.json), npm ci (clean install from lock file, faster and more reliable for CI/CD), npm update (update packages within version ranges), npm outdated (show outdated packages), npm audit (check for vulnerabilities), npm audit fix (automatically fix vulnerabilities). npm scripts enable automation: ```json "scripts": { "prebuild": "npm run clean", "build": "webpack --mode production", "postbuild": "npm run test", "clean": "rm -rf dist", "test": "jest --coverage", "test:watch": "jest --watch", "deploy": "npm run build && firebase deploy" } ``` pre and post hooks automatically run before/after main script. Yarn alternative offers faster installs, better security, offline mode. Yarn commands: yarn install, yarn add, yarn upgrade. Yarn lock file (yarn.lock) similar to package-lock.json. Modern npm (v7+) matches yarn performance. CI/CD integration: ```yaml # GitHub Actions - uses: actions/setup-node@v3 with: node-version: '18' cache: 'npm' - run: npm ci - run: npm run build - run: npm test ``` Private registry configuration (.npmrc): ``` registry=https://registry.npmjs.org/ @myorg:registry=https://npm.company.com/ //npm.company.com/:_authToken=${NPM_TOKEN} ``` Publishing packages: ```bash npm version patch # Increment version npm publish ``` Security practices: npm audit regularly, update dependencies, use exact versions for critical dependencies, scan for known vulnerabilities with Snyk or Dependabot, avoid running npm as root, use .npmrc for private registries, enable 2FA for npm account, use npm ci in CI/CD (ignores package.json, only uses lock file). Understanding npm enables efficient Node.js project management and automation.

3. Explain artifact repository management using Nexus or Artifactory. Include repository types, proxy caching, artifact publishing, promotion workflows, and CI/CD integration.

Difficulty: HardType: SubjectiveTopic: Caching & Artifacts

Artifact repositories manage binary artifacts (JARs, npm packages, Docker images, etc.) providing centralized storage, versioning, and distribution. Major solutions: JFrog Artifactory, Sonatype Nexus, AWS CodeArtifact, Azure Artifacts. Repository types: 1. Hosted repositories store artifacts built internally: - maven-releases (release versions) - maven-snapshots (development snapshots) - npm-private (private npm packages) - docker-private (private Docker images) 2. Proxy repositories cache artifacts from remote sources: - maven-central (proxies Maven Central) - npm-registry (proxies npmjs.com) - docker-hub (proxies Docker Hub) Provides faster downloads, reliability when external sources unavailable, control over external dependencies. 3. Group repositories combine multiple repositories: - maven-public (groups maven-releases, maven-snapshots, maven-central) - npm-group (groups npm-private, npm-registry) Simplifies client configuration (one URL for all sources). Nexus configuration example: Maven client configuration (pom.xml): ```xml <repositories> <repository> <id>nexus</id> <url>https://nexus.company.com/repository/maven-public/</url> </repository> </repositories> <distributionManagement> <repository> <id>nexus-releases</id> <url>https://nexus.company.com/repository/maven-releases/</url> </repository> <snapshotRepository> <id>nexus-snapshots</id> <url>https://nexus.company.com/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement> ``` Credentials in settings.xml (~/.m2/settings.xml): ```xml <settings> <servers> <server> <id>nexus-releases</id> <username>${env.NEXUS_USER}</username> <password>${env.NEXUS_PASSWORD}</password> </server> <server> <id>nexus-snapshots</id> <username>${env.NEXUS_USER}</username> <password>${env.NEXUS_PASSWORD}</password> </server> </servers> </settings> ``` npm configuration (.npmrc): ``` registry=https://nexus.company.com/repository/npm-group/ //nexus.company.com/repository/npm-group/:_authToken=${NPM_TOKEN} ``` Docker registry configuration: ```bash docker login nexus.company.com:5000 docker tag myapp:latest nexus.company.com:5000/myapp:1.0.0 docker push nexus.company.com:5000/myapp:1.0.0 ``` Artifact publishing in CI/CD: Maven: ```yaml deploy: stage: deploy script: - mvn deploy -DskipTests only: - main ``` npm: ```yaml publish: stage: publish script: - echo "//nexus.company.com/repository/npm-private/:_authToken=${NPM_TOKEN}" > .npmrc - npm publish ``` Docker: ```yaml push_image: stage: publish script: - docker build -t nexus.company.com:5000/myapp:${CI_COMMIT_SHA} . - docker push nexus.company.com:5000/myapp:${CI_COMMIT_SHA} ``` Promotion workflows move artifacts between repositories (e.g., staging to production): 1. Build pushes to staging repository 2. Run tests against staging artifacts 3. Manual approval 4. Promote to production repository Nexus promotion (using REST API): ```bash curl -u admin:password -X POST \ "https://nexus.company.com/service/rest/v1/staging/promote" \ -H "Content-Type: application/json" \ -d '{ "data": { "stagedRepositoryId": "staging-repo", "targetRepositoryId": "releases" } }' ``` Artifactory promotion: ```bash jfrog rt build-promote myapp 1.0.0 production-repo --status="Released" ``` Cleanup policies prevent disk space exhaustion: - Remove snapshots older than 30 days - Keep only last 10 versions of each artifact - Delete unused artifacts after 90 days Access control: - Role-based permissions (developer, QA, ops) - Repository-level permissions - Read/write/deploy permissions - Anonymous access for public artifacts Best practices: use group repositories for clients, separate hosted repositories by maturity (snapshot/release), implement cleanup policies, use promotion workflows for production, enable security scanning, monitor storage usage, backup regularly, use HTTPS, implement access control, integrate with SSO. Understanding artifact repository management enables efficient, secure artifact lifecycle management in enterprise CI/CD.

4. Explain Docker multi-stage builds for optimizing images. Include build strategies, layer caching, security considerations, and CI/CD integration.

Difficulty: HardType: SubjectiveTopic: Containerization & Docker

Multi-stage builds separate build and runtime environments, creating smaller, more secure images by excluding build tools and intermediate artifacts from final image. Basic multi-stage example (Node.js): ```dockerfile # Build stage FROM node:18 AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build RUN npm prune --production # Production stage FROM node:18-alpine WORKDIR /app COPY --from=builder /app/dist ./dist COPY --from=builder /app/node_modules ./node_modules COPY package*.json ./ USER node EXPOSE 3000 CMD ["node", "dist/index.js"] ``` Benefits: builder stage includes devDependencies and build tools, production stage only contains runtime dependencies and compiled code, final image significantly smaller (50-80% reduction). Java example with Maven: ```dockerfile # Build stage FROM maven:3.8-jdk-11 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests # Production stage FROM openjdk:11-jre-slim WORKDIR /app COPY --from=builder /app/target/*.jar app.jar USER nobody EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"] ``` Layer caching optimization - order instructions from least to most frequently changing: ```dockerfile FROM node:18 AS builder WORKDIR /app # Cache layer 1: package files (rarely change) COPY package*.json ./ RUN npm ci # Cache layer 2: source code (changes frequently) COPY . . RUN npm run build # Production FROM node:18-alpine WORKDIR /app COPY --from=builder /app/dist ./dist COPY --from=builder /app/node_modules ./node_modules ``` Changes to source code don't invalidate dependency installation layer. BuildKit features (Docker 18.09+): ```dockerfile # syntax=docker/dockerfile:1 FROM node:18 AS builder WORKDIR /app # Mount cache for npm RUN --mount=type=cache,target=/root/.npm \ npm ci # Mount source without copying (faster) RUN --mount=type=bind,source=package.json,target=package.json \ --mount=type=bind,source=src,target=src \ npm run build ``` Security best practices: ```dockerfile FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # Production with security FROM node:18-alpine # Create non-root user RUN addgroup -g 1001 -S nodejs && \ adduser -S nodejs -u 1001 WORKDIR /app # Set ownership COPY --from=builder --chown=nodejs:nodejs /app/dist ./dist COPY --from=builder --chown=nodejs:nodejs /app/node_modules ./node_modules COPY --chown=nodejs:nodejs package*.json ./ # Switch to non-root USER nodejs EXPOSE 3000 CMD ["node", "dist/index.js"] ``` Security measures: use minimal base images (alpine), run as non-root user, scan for vulnerabilities, don't include secrets in image, use .dockerignore to exclude unnecessary files. .dockerignore: ``` node_modules npm-debug.log .git .env *.md .DS_Store tests .github ``` CI/CD integration (GitLab): ```yaml build_image: stage: build image: docker:20.10 services: - docker:20.10-dind variables: DOCKER_TLS_CERTDIR: "/certs" DOCKER_BUILDKIT: 1 script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - | docker build \ --cache-from $CI_REGISTRY_IMAGE:latest \ --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA \ --tag $CI_REGISTRY_IMAGE:latest \ . - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA - docker push $CI_REGISTRY_IMAGE:latest ``` GitHub Actions with caching: ```yaml - name: Set up Docker Buildx uses: docker/setup-buildx-action@v2 - name: Build and push uses: docker/build-push-action@v4 with: context: . push: true tags: | myregistry.com/myapp:${{ github.sha }} myregistry.com/myapp:latest cache-from: type=gha cache-to: type=gha,mode=max ``` Image scanning: ```yaml - name: Scan image uses: aquasecurity/trivy-action@master with: image-ref: 'myapp:${{ github.sha }}' format: 'sarif' output: 'trivy-results.sarif' severity: 'CRITICAL,HIGH' ``` Best practices: use multi-stage builds for all languages, order instructions for optimal caching, use minimal base images, run as non-root, scan images for vulnerabilities, leverage BuildKit caching, use .dockerignore, tag images with commit SHA and semantic version, implement image signing. Understanding Docker optimization creates secure, efficient container images for production deployments.

5. Design a comprehensive continuous testing strategy for CI/CD. Include test types, execution frequency, quality gates, and feedback mechanisms.

Difficulty: HardType: SubjectiveTopic: Test Strategy & Quality

Continuous testing integrates testing throughout development lifecycle with automated execution and rapid feedback. Strategy components: test pyramid implementation, quality gates, shift-left testing, test automation at all levels. Test strategy by pipeline stage: ```yaml stages: - validate - unit-test - build - integration-test - security-scan - deploy-staging - acceptance-test - deploy-production # Stage 1: Pre-commit validation lint: stage: validate script: - npm run lint - npm run format-check only: - merge_requests # Stage 2: Unit tests (every commit) unit-tests: stage: unit-test script: - npm test -- --coverage coverage: '/Statements\s*:\s*(\d+\.\d+)%/' artifacts: reports: coverage_report: coverage_format: cobertura path: coverage/cobertura-coverage.xml rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_COMMIT_BRANCH == "main"' # Stage 3: Build build: stage: build script: - docker build -t myapp:$CI_COMMIT_SHA . dependencies: - unit-tests # Stage 4: Integration tests integration-tests: stage: integration-test services: - postgres:13 - redis:6 script: - npm run test:integration only: - main - merge_requests # Stage 5: Security scanning security-scan: stage: security-scan script: - npm audit --audit-level=high - trivy image myapp:$CI_COMMIT_SHA - semgrep --config=auto src/ allow_failure: false # Stage 6: Deploy to staging deploy-staging: stage: deploy-staging script: - kubectl apply -f k8s/staging/ environment: name: staging only: - main # Stage 7: Acceptance/E2E tests acceptance-tests: stage: acceptance-test script: - npm run test:e2e:staging dependencies: - deploy-staging retry: max: 2 when: script_failure performance-tests: stage: acceptance-test script: - k6 run performance/load-test.js only: - main allow_failure: true # Stage 8: Production deployment deploy-production: stage: deploy-production script: - kubectl apply -f k8s/production/ environment: name: production when: manual only: - main # Smoke tests after production deploy smoke-tests: stage: deploy-production script: - npm run test:smoke:production dependencies: - deploy-production when: on_success ``` Quality gates enforce quality standards: ```javascript // quality-gates.js const qualityGates = { unitTests: { coverage: { statements: 80, branches: 75, functions: 80, lines: 80 }, passRate: 100 // All tests must pass }, staticAnalysis: { criticalIssues: 0, highIssues: 0, codeSmells: 50, duplication: 3 // percent }, security: { criticalVulnerabilities: 0, highVulnerabilities: 0, mediumVulnerabilities: 10 }, performance: { p95ResponseTime: 500, // ms errorRate: 1 // percent } }; function evaluateQualityGates(results) { const failures = []; // Check coverage if (results.coverage.statements < qualityGates.unitTests.coverage.statements) { failures.push(`Statement coverage ${results.coverage.statements}% below threshold`); } // Check vulnerabilities if (results.security.critical > qualityGates.security.criticalVulnerabilities) { failures.push(`${results.security.critical} critical vulnerabilities found`); } if (failures.length > 0) { console.error('Quality gate failed:'); failures.forEach(f => console.error(` - ${f}`)); process.exit(1); } console.log('All quality gates passed'); } ``` Test execution frequency: 1. On every commit: - Linting - Unit tests - Static analysis 2. On merge request: - All commit checks - Integration tests - Security scans - Code coverage 3. On main branch: - All MR checks - E2E tests (smoke suite) - Container scanning - Deploy to staging 4. Nightly: - Full E2E test suite - Performance tests - Cross-browser tests - Visual regression tests - Dependency updates check 5. Weekly: - Penetration testing - Chaos engineering tests - Disaster recovery drills Shift-left testing moves testing earlier: ```javascript // Pre-commit hooks with Husky // .husky/pre-commit #!/bin/sh . "$(dirname "$0")/_/husky.sh" npm run lint npm test -- --findRelatedTests --bail npm run type-check ``` Feedback mechanisms: 1. Pull request annotations: ```yaml test: script: - npm test -- --json --outputFile=test-results.json after_script: - node scripts/annotate-pr.js test-results.json ``` 2. Slack notifications: ```yaml notify: stage: .post script: - | curl -X POST $SLACK_WEBHOOK \ -d "{ 'text': 'Pipeline ${CI_PIPELINE_STATUS} for ${CI_COMMIT_REF_NAME}', 'attachments': [{ 'color': '${CI_PIPELINE_STATUS == "success" ? "good" : "danger"}', 'fields': [ {'title': 'Project', 'value': '${CI_PROJECT_NAME}'}, {'title': 'Branch', 'value': '${CI_COMMIT_REF_NAME}'}, {'title': 'Coverage', 'value': '${COVERAGE}%'} ] }] }" when: always ``` 3. Dashboard metrics: ```javascript // Collect test metrics const metrics = { timestamp: new Date(), pipeline: process.env.CI_PIPELINE_ID, branch: process.env.CI_COMMIT_BRANCH, unitTests: { total: testResults.numTotalTests, passed: testResults.numPassedTests, failed: testResults.numFailedTests, duration: testResults.testResults.reduce((sum, r) => sum + r.perfStats.end - r.perfStats.start, 0) }, coverage: { statements: coverage.total.statements.pct, branches: coverage.total.branches.pct } }; // Send to monitoring system await sendMetrics(metrics); ``` 4. Test trend analysis: ```python # Analyze test trends import pandas as pd import matplotlib.pyplot as plt df = pd.read_csv('test-history.csv') df['date'] = pd.to_datetime(df['date']) # Plot coverage trend plt.plot(df['date'], df['coverage']) plt.axhline(y=80, color='r', linestyle='--', label='Threshold') plt.xlabel('Date') plt.ylabel('Coverage %') plt.title('Test Coverage Trend') plt.savefig('coverage-trend.png') ``` Best practices: 1. Fail fast (run fastest tests first) 2. Test in production-like environment 3. Automate everything 4. Make tests deterministic 5. Maintain test hygiene (remove obsolete tests) 6. Monitor test health metrics 7. Provide clear failure messages 8. Enable easy local reproduction 9. Balance speed and coverage 10. Continuous improvement (review metrics, optimize) Understanding continuous testing strategy ensures quality built into entire development process with rapid, automated feedback.

6. Explain TDD and BDD practices in CI/CD. Include Red-Green-Refactor cycle, Gherkin syntax, automation strategies, and integration with pipelines.

Difficulty: HardType: SubjectiveTopic: Testing Fundamentals

Test-Driven Development (TDD) follows Red-Green-Refactor cycle. Red: write failing test defining expected behavior before implementation. Green: write minimal code passing the test. Refactor: improve code quality while keeping tests passing. TDD example: ```javascript // Red: Write failing test test('calculate total with discount', () => { const cart = new ShoppingCart(); cart.addItem({ price: 100, quantity: 2 }); expect(cart.getTotal(0.1)).toBe(180); // 10% discount }); // Green: Minimal implementation class ShoppingCart { constructor() { this.items = []; } addItem(item) { this.items.push(item); } getTotal(discount = 0) { const subtotal = this.items.reduce( (sum, item) => sum + (item.price * item.quantity), 0 ); return subtotal * (1 - discount); } } // Refactor: Add validation, error handling class ShoppingCart { constructor() { this.items = []; } addItem(item) { if (!item.price || item.price < 0) { throw new Error('Invalid price'); } if (!item.quantity || item.quantity < 1) { throw new Error('Invalid quantity'); } this.items.push(item); } getTotal(discount = 0) { if (discount < 0 || discount > 1) { throw new Error('Discount must be between 0 and 1'); } const subtotal = this.items.reduce( (sum, item) => sum + (item.price * item.quantity), 0 ); return subtotal * (1 - discount); } } // Add more tests for edge cases test('throws error on invalid discount', () => { const cart = new ShoppingCart(); cart.addItem({ price: 100, quantity: 1 }); expect(() => cart.getTotal(1.5)).toThrow('Discount must be between 0 and 1'); }); ``` TDD benefits: better design (tests drive API design), high coverage (tests written first), fewer bugs, confidence in refactoring, living documentation. Behavior-Driven Development (BDD) extends TDD using business-readable language (Gherkin): ```gherkin Feature: Shopping Cart As a customer I want to manage items in my cart So that I can purchase products Background: Given I am logged in as "customer@example.com" Scenario: Add item to cart Given I am on the product page for "iPhone 15" When I click "Add to Cart" Then I should see "1 item in cart" And the cart total should be "$999" Scenario: Apply discount code Given I have 1 "iPhone 15" in my cart When I apply discount code "SAVE10" Then the cart total should be "$899.10" And I should see "Discount applied: 10%" Scenario Outline: Bulk purchase discount Given I have <quantity> "iPhone 15" in my cart When I proceed to checkout Then I should receive <discount>% discount And the total should be <total> Examples: | quantity | discount | total | | 1 | 0 | $999.00 | | 5 | 5 | $4745.25 | | 10 | 10 | $8991.00 | ``` Step definitions implement scenarios: ```javascript const { Given, When, Then } = require('@cucumber/cucumber'); const { expect } = require('chai'); Given('I am logged in as {string}', async function (email) { this.user = await loginUser(email); }); Given('I am on the product page for {string}', async function (product) { await this.page.goto(`/products/${product}`); }); When('I click {string}', async function (buttonText) { await this.page.click(`button:has-text("${buttonText}")`); }); Then('I should see {string}', async function (text) { await expect(this.page.locator('body')).toContainText(text); }); Then('the cart total should be {string}', async function (amount) { const total = await this.page.locator('[data-test="cart-total"]').textContent(); expect(total).to.equal(amount); }); When('I apply discount code {string}', async function (code) { await this.page.fill('[data-test="discount-code"]', code); await this.page.click('[data-test="apply-discount"]'); }); ``` CI/CD integration: ```yaml # GitLab CI stages: - unit-test - integration-test - bdd-test unit-tests: stage: unit-test script: - npm test coverage: '/Statements\s*:\s*(\d+\.\d+)%/' rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' - if: '$CI_COMMIT_BRANCH == "main"' integration-tests: stage: integration-test services: - postgres:13 script: - npm run test:integration only: - main bdd-tests: stage: bdd-test script: - npm run cucumber artifacts: when: always reports: junit: reports/cucumber-report.xml paths: - reports/ only: - main - /^release/.*$/ ``` GitHub Actions: ```yaml name: TDD/BDD Pipeline on: [push, pull_request] jobs: unit-tests: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '18' cache: 'npm' - run: npm ci - run: npm test - uses: codecov/codecov-action@v3 bdd-tests: runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' steps: - uses: actions/checkout@v3 - run: npm ci - run: npm run cucumber - uses: actions/upload-artifact@v3 if: always() with: name: cucumber-report path: reports/ ``` Best practices: write tests first (TDD discipline), keep tests fast, make tests deterministic, use descriptive names, test behaviors not implementation, refactor tests regularly, run TDD unit tests on every commit, run BDD acceptance tests on main branch or before release, enforce coverage thresholds, review tests in pull requests. Understanding TDD/BDD integrates quality into development process from start.

7. Explain test data management strategies including data generation, test fixtures, database seeding, and data privacy considerations in CI/CD.

Difficulty: MediumType: SubjectiveTopic: Test Strategy & Quality

Test data management ensures tests have consistent, realistic data without exposing sensitive information. Strategies: synthetic data generation, database seeding, test fixtures, data masking. Synthetic data generation creates realistic test data: ```javascript // Faker.js for realistic data const { faker } = require('@faker-js/faker'); function generateTestUser() { return { id: faker.string.uuid(), email: faker.internet.email(), firstName: faker.person.firstName(), lastName: faker.person.lastName(), phone: faker.phone.number(), address: { street: faker.location.streetAddress(), city: faker.location.city(), zipCode: faker.location.zipCode(), }, createdAt: faker.date.past(), }; } const testUsers = Array.from({ length: 100 }, generateTestUser); ``` Test fixtures provide consistent test data: ```python # pytest fixtures import pytest @pytest.fixture def test_user(): return { 'id': 1, 'email': 'test@example.com', 'name': 'Test User' } @pytest.fixture def database(tmp_path): db_path = tmp_path / "test.db" db = Database(db_path) db.create_tables() yield db db.close() def test_create_user(database, test_user): user_id = database.create_user(test_user) assert user_id == test_user['id'] ``` Database seeding for integration tests: ```javascript // seeds/test-data.js exports.seed = async function(knex) { await knex('users').del(); await knex('products').del(); await knex('users').insert([ { id: 1, email: 'user1@example.com', role: 'customer' }, { id: 2, email: 'admin@example.com', role: 'admin' }, ]); await knex('products').insert([ { id: 1, name: 'Product 1', price: 99.99, stock: 100 }, { id: 2, name: 'Product 2', price: 149.99, stock: 50 }, ]); }; // Run in tests beforeEach(async () => { await knex.migrate.latest(); await knex.seed.run(); }); afterEach(async () => { await knex.migrate.rollback(); }); ``` Testcontainers with seeded database: ```java @Container private static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:13") .withDatabaseName("testdb") .withInitScript("test-data.sql"); @BeforeEach void setUp() { DataSource dataSource = createDataSource(postgres.getJdbcUrl()); userRepository = new UserRepository(dataSource); } ``` test-data.sql: ```sql INSERT INTO users (id, email, name) VALUES (1, 'test1@example.com', 'Test User 1'), (2, 'test2@example.com', 'Test User 2'); INSERT INTO orders (id, user_id, total, status) VALUES (1, 1, 99.99, 'completed'), (2, 1, 149.99, 'pending'); ``` Data masking for production data: ```python # Mask sensitive data from production backup import hashlib def mask_email(email): username, domain = email.split('@') return f"{username[:2]}***@{domain}" def mask_phone(phone): return f"***-***-{phone[-4:]}" def anonymize_user(user): return { **user, 'email': mask_email(user['email']), 'phone': mask_phone(user['phone']), 'ssn': hashlib.sha256(user['ssn'].encode()).hexdigest()[:10], 'credit_card': None, } # Apply to production data export with open('production_users.json') as f: users = json.load(f) masked_users = [anonymize_user(u) for u in users] with open('test_users.json', 'w') as f: json.dump(masked_users, f) ``` CI/CD data management: ```yaml # GitLab CI test: stage: test services: - postgres:13 variables: DATABASE_URL: "postgresql://test:test@postgres:5432/testdb" before_script: - npm run db:migrate - npm run db:seed script: - npm test after_script: - npm run db:reset ``` Factory pattern for test objects: ```javascript // factories/user.factory.js class UserFactory { static build(overrides = {}) { return { id: faker.string.uuid(), email: faker.internet.email(), name: faker.person.fullName(), role: 'customer', createdAt: new Date(), ...overrides }; } static buildAdmin() { return this.build({ role: 'admin' }); } static async create(overrides = {}) { const user = this.build(overrides); return await database.users.create(user); } } // Usage in tests test('admin can delete users', async () => { const admin = await UserFactory.create({ role: 'admin' }); const user = await UserFactory.create(); const result = await deleteUser(admin, user.id); expect(result).toBe(true); }); ``` Data privacy considerations: 1. Never use real production data directly 2. Mask PII (personally identifiable information) 3. Use synthetic data for tests 4. Secure test data storage 5. Rotate test credentials regularly 6. Document data classification 7. Comply with GDPR, CCPA requirements Best practices: use factories for object creation, seed minimal required data, clean up after tests, isolate test data per test, version control seed files, automate data generation, use realistic but fake data, implement data refresh strategies. Understanding test data management ensures reliable, privacy-compliant tests.

8. Explain Canary release implementation including traffic routing, metrics monitoring, automated promotion/rollback, and integration with service mesh.

Difficulty: HardType: SubjectiveTopic: Deployment Strategies

Canary releases progressively roll out new version monitoring metrics to detect issues early. Implementation requires: traffic routing capability, comprehensive monitoring, automated decision making, rollback mechanism. Traffic routing methods: 1. Load balancer weight-based routing: ```yaml # AWS ALB target groups resource "aws_lb_listener_rule" "canary" { listener_arn = aws_lb_listener.main.arn action { type = "forward" forward { target_group { arn = aws_lb_target_group.stable.arn weight = 90 } target_group { arn = aws_lb_target_group.canary.arn weight = 10 } } } } ``` 2. Kubernetes with Flagger (service mesh): ```yaml apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: myapp spec: targetRef: apiVersion: apps/v1 kind: Deployment name: myapp service: port: 80 analysis: interval: 1m threshold: 5 maxWeight: 50 stepWeight: 10 metrics: - name: request-success-rate thresholdRange: min: 99 interval: 1m - name: request-duration thresholdRange: max: 500 interval: 1m webhooks: - name: load-test url: http://flagger-loadtester/ timeout: 5s metadata: cmd: "hey -z 1m -q 10 -c 2 http://myapp-canary/" ``` 3. Istio traffic splitting: ```yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: myapp spec: hosts: - myapp http: - match: - headers: x-canary: exact: "true" route: - destination: host: myapp subset: canary - route: - destination: host: myapp subset: stable weight: 90 - destination: host: myapp subset: canary weight: 10 --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: myapp spec: host: myapp subsets: - name: stable labels: version: stable - name: canary labels: version: canary ``` Metrics monitoring for canary analysis: ```python class CanaryMetrics: def __init__(self, stable_version, canary_version): self.stable = stable_version self.canary = canary_version def analyze(self): metrics = { 'error_rate': self.compare_error_rate(), 'latency_p95': self.compare_latency(), 'latency_p99': self.compare_latency(percentile=99), 'throughput': self.compare_throughput(), 'cpu_usage': self.compare_cpu(), 'memory_usage': self.compare_memory() } # Business metrics business_metrics = { 'conversion_rate': self.compare_conversion(), 'cart_abandonment': self.compare_abandonment(), 'avg_order_value': self.compare_aov() } return self.evaluate(metrics, business_metrics) def compare_error_rate(self): stable_errors = self.get_metric('error_rate', self.stable) canary_errors = self.get_metric('error_rate', self.canary) # Canary error rate should not exceed stable by more than 1% threshold = stable_errors + 1.0 return { 'stable': stable_errors, 'canary': canary_errors, 'threshold': threshold, 'passed': canary_errors <= threshold } def evaluate(self, metrics, business_metrics): failed = [] for name, result in {**metrics, **business_metrics}.items(): if not result['passed']: failed.append(f"{name}: {result['canary']} vs {result['stable']}") if failed: return {'decision': 'ROLLBACK', 'reasons': failed} else: return {'decision': 'PROMOTE', 'reasons': []} ``` Automated canary progression: ```bash #!/bin/bash # canary-deploy.sh VERSION=$1 STAGES=(10 25 50 75 100) function deploy_canary() { local weight=$1 echo "Setting canary weight to $weight%" kubectl patch virtualservice myapp --type=json -p='[ {"op": "replace", "path": "/spec/http/0/route/0/weight", "value": '$((100-weight))'}, {"op": "replace", "path": "/spec/http/0/route/1/weight", "value": '$weight'} ]' } function analyze_canary() { python3 analyze-canary.py --stable=stable --canary=canary --duration=5m return $? } function rollback() { echo "Rolling back canary" deploy_canary 0 kubectl delete deployment myapp-canary exit 1 } # Deploy canary deployment kubectl apply -f k8s/canary-deployment.yaml # Progressive rollout for stage in "${STAGES[@]}"; do echo "\n=== Canary stage: $stage% ===" deploy_canary $stage echo "Monitoring for 5 minutes..." if ! analyze_canary; then echo "Canary analysis failed" rollback fi if [ $stage -eq 100 ]; then echo "Canary fully deployed" kubectl delete deployment myapp-stable kubectl apply -f k8s/stable-deployment.yaml fi done ``` Flagger automated canary: ```yaml # Flagger automatically handles progressive rollout apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: myapp spec: progressDeadlineSeconds: 600 service: port: 80 analysis: interval: 1m threshold: 5 iterations: 10 match: - headers: x-canary: exact: "insider" metrics: - name: error-rate templateRef: name: error-rate thresholdRange: max: 1 - name: latency templateRef: name: latency thresholdRange: max: 500 webhooks: - name: acceptance-test type: pre-rollout url: http://flagger-loadtester/ timeout: 30s metadata: type: bash cmd: "curl -sd 'test' http://myapp-canary/token | grep token" - name: load-test type: rollout url: http://flagger-loadtester/ metadata: cmd: "hey -z 2m -q 10 -c 2 http://myapp-canary/" ``` Monitoring dashboard configuration: ```json { "dashboard": { "title": "Canary Deployment", "panels": [ { "title": "Error Rate", "targets": [ { "expr": "sum(rate(http_requests_total{status=~\"5..\", version=\"stable\"}[5m])) / sum(rate(http_requests_total{version=\"stable\"}[5m])) * 100", "legendFormat": "Stable" }, { "expr": "sum(rate(http_requests_total{status=~\"5..\", version=\"canary\"}[5m])) / sum(rate(http_requests_total{version=\"canary\"}[5m])) * 100", "legendFormat": "Canary" } ] }, { "title": "Latency P95", "targets": [ { "expr": "histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{version=\"stable\"}[5m])) by (le))", "legendFormat": "Stable" }, { "expr": "histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{version=\"canary\"}[5m])) by (le))", "legendFormat": "Canary" } ] } ] } } ``` CI/CD integration: ```yaml stages: - build - deploy-canary - analyze - promote deploy-canary: stage: deploy-canary script: - kubectl apply -f k8s/canary/ - kubectl annotate canary/myapp flagger.app/trigger="$CI_COMMIT_SHA" only: - main monitor-canary: stage: analyze script: - ./wait-for-canary.sh myapp timeout: 30m promote-canary: stage: promote script: - kubectl get canary myapp -o json | jq '.status.phase' when: on_success ``` Best practices: start with small percentage (5-10%), monitor comprehensive metrics (technical and business), implement automated analysis, use service mesh for advanced routing, test rollback procedures, implement gradual rollout stages, use statistical significance testing, combine with feature flags for additional control, maintain observability throughout rollout. Understanding canary releases enables safe, data-driven progressive deployments.

9. Explain feature flag systems including implementation patterns, targeting rules, A/B testing integration, and lifecycle management. Include examples with LaunchDarkly or custom implementations.

Difficulty: HardType: SubjectiveTopic: Environment Management

Feature flags decouple deployment from release enabling runtime feature control without code changes. Implementation levels: simple boolean flags, percentage rollouts, user targeting, multivariate flags. Basic feature flag implementation: ```javascript // Simple in-memory flags class FeatureFlags { constructor() { this.flags = new Map(); } setFlag(name, enabled) { this.flags.set(name, enabled); } isEnabled(name, defaultValue = false) { return this.flags.get(name) ?? defaultValue; } } const flags = new FeatureFlags(); // Usage if (flags.isEnabled('new-checkout')) { return newCheckoutFlow(); } else { return oldCheckoutFlow(); } ``` Advanced flags with user targeting: ```javascript class FeatureFlagService { constructor(config) { this.config = config; } isEnabled(flagName, context = {}) { const flag = this.config.flags[flagName]; if (!flag) return false; // Check if globally enabled if (flag.enabled === false) return false; // Check user targeting if (flag.targeting) { return this.evaluateTargeting(flag.targeting, context); } // Check percentage rollout if (flag.rolloutPercentage !== undefined) { return this.evaluatePercentage( flagName, context.userId, flag.rolloutPercentage ); } return flag.enabled; } evaluateTargeting(rules, context) { // User ID targeting if (rules.userIds && context.userId) { if (rules.userIds.includes(context.userId)) { return true; } } // Email domain targeting if (rules.emailDomains && context.email) { const domain = context.email.split('@')[1]; if (rules.emailDomains.includes(domain)) { return true; } } // Custom attributes if (rules.attributes) { return Object.entries(rules.attributes).every(([key, value]) => { return context[key] === value; }); } return false; } evaluatePercentage(flagName, userId, percentage) { // Consistent hashing for same user const hash = this.hashCode(flagName + userId); const bucket = Math.abs(hash) % 100; return bucket < percentage; } hashCode(str) { let hash = 0; for (let i = 0; i < str.length; i++) { const char = str.charCodeAt(i); hash = ((hash << 5) - hash) + char; hash = hash & hash; } return hash; } } // Configuration const config = { flags: { 'new-checkout': { enabled: true, rolloutPercentage: 25, targeting: { emailDomains: ['company.com'], userIds: ['beta-user-1', 'beta-user-2'] } }, 'premium-features': { enabled: true, targeting: { attributes: { plan: 'premium' } } } } }; const flagService = new FeatureFlagService(config); // Usage with context const user = { userId: '12345', email: 'user@company.com', plan: 'premium' }; if (flagService.isEnabled('new-checkout', user)) { // Show new checkout } ``` LaunchDarkly integration: ```javascript const LaunchDarkly = require('launchdarkly-node-server-sdk'); const ldClient = LaunchDarkly.init('YOUR_SDK_KEY'); await ldClient.waitForInitialization(); const user = { key: 'user-key-123', email: 'user@example.com', custom: { plan: 'premium', signupDate: '2024-01-01' } }; // Boolean flag const showNewFeature = await ldClient.variation( 'new-feature', user, false // default ); // Multivariate flag const buttonColor = await ldClient.variation( 'button-color', user, 'blue' // default ); // JSON flag for complex configuration const config = await ldClient.variation( 'app-config', user, { theme: 'light', maxItems: 10 } ); ``` A/B testing with feature flags: ```javascript class ABTestingService { constructor(flagService, analyticsService) { this.flags = flagService; this.analytics = analyticsService; } getVariant(experimentName, context) { const flag = this.flags.getFlag(experimentName); if (!flag || !flag.experiment) { return 'control'; } // Assign variant based on user const variant = this.assignVariant( experimentName, context.userId, flag.experiment.variants ); // Track assignment this.analytics.track('Experiment Viewed', { experimentName, variant, userId: context.userId }); return variant; } assignVariant(experimentName, userId, variants) { const hash = this.hashCode(experimentName + userId); const bucket = Math.abs(hash) % 100; let cumulative = 0; for (const [variant, percentage] of Object.entries(variants)) { cumulative += percentage; if (bucket < cumulative) { return variant; } } return 'control'; } trackConversion(experimentName, context, metric, value) { const variant = this.getVariant(experimentName, context); this.analytics.track('Experiment Conversion', { experimentName, variant, metric, value, userId: context.userId }); } } // Usage const variant = abTesting.getVariant('checkout-redesign', { userId: '123' }); if (variant === 'treatment') { showNewCheckout(); } else { showOldCheckout(); } // Track conversion abTesting.trackConversion( 'checkout-redesign', { userId: '123' }, 'purchase', 99.99 ); ``` Flag lifecycle management: ```javascript class FlagLifecycleManager { constructor() { this.flags = new Map(); } createFlag(name, config) { this.flags.set(name, { ...config, createdAt: new Date(), status: 'pending', rolloutHistory: [] }); } updateRollout(name, percentage) { const flag = this.flags.get(name); flag.rolloutHistory.push({ percentage, timestamp: new Date() }); flag.rolloutPercentage = percentage; if (percentage === 100) { flag.status = 'complete'; } } retireFlag(name) { const flag = this.flags.get(name); flag.status = 'retired'; flag.retiredAt = new Date(); } getOldFlags(daysOld = 90) { const cutoff = new Date(); cutoff.setDate(cutoff.getDate() - daysOld); return Array.from(this.flags.entries()) .filter(([name, flag]) => { return flag.status === 'complete' && flag.rolloutHistory.length > 0 && flag.rolloutHistory[flag.rolloutHistory.length - 1].timestamp < cutoff; }) .map(([name]) => name); } } ``` CI/CD integration: ```yaml deploy: stage: deploy script: # Deploy with flag disabled - kubectl apply -f k8s/ # Enable flag for internal users - | curl -X PATCH https://app.launchdarkly.com/api/v2/flags/my-project/new-feature \ -H "Authorization: $LD_API_KEY" \ -d '{ "instructions": [{ "kind": "updateFallthroughVariationOrRollout", "rollout": { "variations": [ {"variation": 0, "weight": 95000}, {"variation": 1, "weight": 5000} ] } }] }' # Monitor metrics - ./monitor-rollout.sh new-feature 5m # Gradually increase - ./update-flag-percentage.sh new-feature 25 ``` Best practices: use descriptive flag names, document flag purpose and owner, implement flag cleanup process (retire old flags), separate long-term operational flags from temporary release flags, use targeting for staged rollouts, implement audit logging for flag changes, test both flag states, avoid flag dependencies (flags depending on other flags), use SDK with caching for performance, implement flag evaluation metrics. Understanding feature flags enables safe, gradual feature releases with instant kill switch capability.

10. Design comprehensive environment management strategy including environment types, configuration management, secrets handling, and environment parity.

Difficulty: MediumType: SubjectiveTopic: Environment Management

Environment strategy defines progression from development to production ensuring quality while managing complexity. Standard environments: local (developer machine), development (shared dev environment), staging (pre-production), production (live users). Optional: QA (dedicated testing), UAT (user acceptance), integration (service integration testing), performance (load testing), canary (progressive rollout). Environment characteristics: Local development: ```yaml # docker-compose.yml for local version: '3.8' services: app: build: . environment: - NODE_ENV=development - DATABASE_URL=postgresql://localhost:5432/dev - REDIS_URL=redis://localhost:6379 - LOG_LEVEL=debug volumes: - ./src:/app/src # Hot reload ports: - "3000:3000" postgres: image: postgres:13 environment: - POSTGRES_DB=dev - POSTGRES_PASSWORD=dev volumes: - postgres-data:/var/lib/postgresql/data redis: image: redis:6 ``` Development environment: ```yaml # k8s/dev/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp namespace: development spec: replicas: 1 template: spec: containers: - name: myapp image: myapp:latest env: - name: ENVIRONMENT value: "development" - name: DATABASE_URL valueFrom: secretKeyRef: name: db-credentials key: url resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "500m" ``` Staging environment (production-like): ```yaml # k8s/staging/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp namespace: staging spec: replicas: 2 # Similar to production template: spec: containers: - name: myapp image: myapp:v1.2.3 # Tagged version env: - name: ENVIRONMENT value: "staging" resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1000m" affinity: # Similar to production podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: myapp topologyKey: kubernetes.io/hostname ``` Production environment: ```yaml # k8s/production/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp namespace: production spec: replicas: 5 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: spec: containers: - name: myapp image: myapp:v1.2.3 env: - name: ENVIRONMENT value: "production" livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1000m" ``` Configuration management per environment: ```javascript // config/index.js const configs = { development: { api: { baseUrl: 'http://localhost:3000', timeout: 30000 }, features: { newCheckout: true, analytics: false }, database: { pool: { min: 2, max: 10 } } }, staging: { api: { baseUrl: 'https://api-staging.example.com', timeout: 10000 }, features: { newCheckout: true, analytics: true }, database: { pool: { min: 5, max: 20 } } }, production: { api: { baseUrl: 'https://api.example.com', timeout: 5000 }, features: { newCheckout: false, analytics: true }, database: { pool: { min: 10, max: 50 } } } }; module.exports = configs[process.env.NODE_ENV || 'development']; ``` Secrets management: ```yaml # Using Sealed Secrets (encrypted in Git) apiVersion: bitnami.com/v1alpha1 kind: SealedSecret metadata: name: db-credentials namespace: production spec: encryptedData: url: AgBH7Vw8K... # Encrypted value --- # Using External Secrets Operator (from Vault) apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: db-credentials spec: refreshInterval: 1h secretStoreRef: name: vault-backend kind: SecretStore target: name: db-credentials data: - secretKey: url remoteRef: key: database/production property: connection_url ``` Environment parity checklist: 1. Same infrastructure components (load balancer, database, cache) 2. Similar resource allocation (staging = 50% of production) 3. Same configuration structure (different values) 4. Same monitoring and logging 5. Same deployment process 6. Realistic data volumes in staging Terraform workspaces for environment management: ```hcl # main.tf terraform { backend "s3" { bucket = "terraform-state" key = "myapp/terraform.tfstate" region = "us-east-1" } } variable "environment" { type = string } locals { config = { dev = { instance_count = 1 instance_type = "t3.small" db_instance = "db.t3.micro" } staging = { instance_count = 2 instance_type = "t3.medium" db_instance = "db.t3.small" } production = { instance_count = 5 instance_type = "t3.large" db_instance = "db.r5.large" } } env_config = local.config[var.environment] } resource "aws_instance" "app" { count = local.env_config.instance_count instance_type = local.env_config.instance_type tags = { Environment = var.environment } } ``` CI/CD pipeline with environment progression: ```yaml stages: - build - deploy-dev - test-dev - deploy-staging - test-staging - deploy-production deploy-dev: stage: deploy-dev script: - ./deploy.sh dev $CI_COMMIT_SHA environment: name: development url: https://dev.example.com only: - branches test-dev: stage: test-dev script: - npm run test:integration -- --env=dev deploy-staging: stage: deploy-staging script: - ./deploy.sh staging $CI_COMMIT_SHA environment: name: staging url: https://staging.example.com only: - main test-staging: stage: test-staging script: - npm run test:e2e -- --env=staging - npm run test:performance -- --env=staging deploy-production: stage: deploy-production script: - ./deploy.sh production $CI_COMMIT_TAG environment: name: production url: https://example.com when: manual only: - tags ``` Best practices: maintain environment parity (staging mirrors production), automate environment provisioning (Infrastructure as Code), isolate environments (separate networks/accounts), use consistent naming, implement proper access control, document environment differences, use environment-specific configurations, test production deployment in staging first, maintain separate credentials per environment, implement cost controls (auto-shutdown dev environments), regular environment refresh (reset staging data). Understanding environment management ensures quality progression to production.

11. Explain Maven project structure, lifecycle, dependency management, and plugins. Include pom.xml configuration, repository management, and CI/CD integration best practices.

Difficulty: HardType: SubjectiveTopic: Build Tools

Maven project structure follows convention over configuration. Standard directory layout: ``` project/ ├── pom.xml ├── src/ │ ├── main/ │ │ ├── java/ # Source code │ │ ├── resources/ # Config files │ │ └── webapp/ # Web resources (for WAR) │ └── test/ │ ├── java/ # Test code │ └── resources/ # Test resources └── target/ # Build output ``` pom.xml (Project Object Model) defines project configuration: ```xml <project> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>myapp</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>jar</packaging> <properties> <maven.compiler.source>11</maven.compiler.source> <maven.compiler.target>11</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>2.7.0</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.13.2</version> <scope>test</scope> </dependency> </dependencies> </project> ``` Maven lifecycle phases: validate (validate project correctness), compile (compile source code), test (run unit tests), package (create JAR/WAR), verify (run integration tests), install (install to local repository), deploy (deploy to remote repository). Each phase executes all previous phases. Dependency management uses transitive dependencies (automatically includes dependencies of dependencies). Dependency scopes: compile (default, available everywhere), provided (available at compile but not included in package), runtime (needed at runtime but not compile), test (only for tests), system (like provided but specified via systemPath). Example: ```xml <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> # Servlet container provides this </dependency> ``` Dependency exclusions prevent transitive dependency issues: ```xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </exclusion> </exclusions> </dependency> ``` Dependency management section defines versions centrally: ```xml <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>2.7.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> ``` Plugins extend Maven functionality: ```xml <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.10.1</version> <configuration> <source>11</source> <target>11</target> </configuration> </plugin> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> ``` Repository configuration: ```xml <repositories> <repository> <id>central</id> <url>https://repo1.maven.org/maven2</url> </repository> <repository> <id>company-repo</id> <url>https://nexus.company.com/repository/maven-public/</url> </repository> </repositories> <distributionManagement> <repository> <id>releases</id> <url>https://nexus.company.com/repository/maven-releases/</url> </repository> <snapshotRepository> <id>snapshots</id> <url>https://nexus.company.com/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement> ``` CI/CD integration: ```yaml # GitLab CI build: image: maven:3.8-jdk-11 script: - mvn clean package artifacts: paths: - target/*.jar cache: key: ${CI_COMMIT_REF_SLUG} paths: - .m2/repository ``` Settings.xml for credentials (~/.m2/settings.xml): ```xml <settings> <servers> <server> <id>releases</id> <username>${env.NEXUS_USER}</username> <password>${env.NEXUS_PASSWORD}</password> </server> </servers> <mirrors> <mirror> <id>company-mirror</id> <mirrorOf>*</mirrorOf> <url>https://nexus.company.com/repository/maven-public/</url> </mirror> </mirrors> </settings> ``` Best practices: use dependency management for version consistency, leverage Bill of Materials (BOM) for related dependencies, cache .m2/repository in CI/CD, use Maven wrapper for version consistency, skip tests during package if already run (mvn package -DskipTests), parallel builds (mvn -T 4 package), offline mode for faster builds with cached dependencies (mvn -o package). Understanding Maven enables efficient Java project automation.

12. Explain Blue-Green deployment implementation including infrastructure setup, traffic switching, database considerations, rollback procedures, and CI/CD integration.

Difficulty: HardType: SubjectiveTopic: Deployment Strategies

Blue-Green deployment maintains two identical production environments enabling instant traffic switching. Infrastructure setup requires: two complete environments (compute, networking, databases), load balancer or DNS for traffic routing, monitoring for both environments, automation for deployment and switching. Infrastructure patterns: 1. Load Balancer switching (AWS ELB): ```yaml # Terraform example resource "aws_lb_target_group" "blue" { name = "app-blue" port = 80 protocol = "HTTP" vpc_id = aws_vpc.main.id health_check { path = "/health" healthy_threshold = 2 unhealthy_threshold = 2 timeout = 5 } } resource "aws_lb_target_group" "green" { name = "app-green" port = 80 protocol = "HTTP" vpc_id = aws_vpc.main.id health_check { path = "/health" healthy_threshold = 2 unhealthy_threshold = 2 } } resource "aws_lb_listener" "main" { load_balancer_arn = aws_lb.main.arn port = 80 protocol = "HTTP" default_action { type = "forward" target_group_arn = var.active_environment == "blue" ? aws_lb_target_group.blue.arn : aws_lb_target_group.green.arn } } ``` 2. Kubernetes Service switching: ```yaml apiVersion: v1 kind: Service metadata: name: myapp spec: selector: app: myapp version: blue # Switch to 'green' for deployment ports: - port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: myapp-blue spec: replicas: 3 selector: matchLabels: app: myapp version: blue template: metadata: labels: app: myapp version: blue spec: containers: - name: myapp image: myapp:v1 --- apiVersion: apps/v1 kind: Deployment metadata: name: myapp-green spec: replicas: 3 selector: matchLabels: app: myapp version: green template: metadata: labels: app: myapp version: green spec: containers: - name: myapp image: myapp:v2 ``` Deployment process: 1. Deploy to inactive environment (Green) 2. Run smoke tests on Green 3. Run full test suite on Green 4. Switch small percentage for canary testing (optional) 5. Monitor Green environment metrics 6. Switch all traffic to Green 7. Monitor for issues 8. Keep Blue running as backup Database considerations (biggest challenge): Backward compatible migrations: ```sql -- Phase 1: Add new column (nullable) ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT NULL; -- Deploy Green with code using new column -- Both Blue and Green work -- Phase 2: Backfill data UPDATE users SET email_verified = FALSE WHERE email_verified IS NULL; -- Phase 3: Make non-nullable (after Blue retired) ALTER TABLE users ALTER COLUMN email_verified SET NOT NULL; ``` Database patterns: 1. Shared database (both Blue and Green use same DB): - Simple but requires backward compatible migrations - Blue and Green must handle old and new schema 2. Database per environment: - Complete isolation - Complex data synchronization - Expensive (duplicate data) 3. Read replicas: - Blue uses primary, Green uses replica for testing - Promote replica during switch Traffic switching automation: ```bash #!/bin/bash # blue-green-switch.sh CURRENT_ENV=$1 NEW_ENV=$2 echo "Current: $CURRENT_ENV, Switching to: $NEW_ENV" # Deploy to new environment kubectl apply -f k8s/$NEW_ENV/ # Wait for pods ready kubectl wait --for=condition=ready pod -l version=$NEW_ENV --timeout=300s # Run smoke tests ./smoke-tests.sh https://$NEW_ENV.internal.example.com if [ $? -ne 0 ]; then echo "Smoke tests failed, aborting" exit 1 fi # Switch traffic kubectl patch service myapp -p '{"spec":{"selector":{"version":"'$NEW_ENV'"}}}' echo "Switched to $NEW_ENV" # Monitor for 5 minutes sleep 300 # Check error rate ERROR_RATE=$(curl -s "https://metrics.example.com/error-rate?env=$NEW_ENV") if [ "$ERROR_RATE" -gt 5 ]; then echo "High error rate: $ERROR_RATE%, rolling back" kubectl patch service myapp -p '{"spec":{"selector":{"version":"'$CURRENT_ENV'"}}}' exit 1 fi echo "Deployment successful" ``` CI/CD integration: ```yaml stages: - build - deploy-green - test-green - switch-traffic - cleanup build: stage: build script: - docker build -t myapp:$CI_COMMIT_SHA . - docker push myapp:$CI_COMMIT_SHA deploy-green: stage: deploy-green script: - export NEW_ENV="green" - export OLD_ENV="blue" - ./deploy.sh $NEW_ENV $CI_COMMIT_SHA environment: name: green url: https://green.internal.example.com test-green: stage: test-green script: - ./smoke-tests.sh https://green.internal.example.com - ./integration-tests.sh https://green.internal.example.com switch-traffic: stage: switch-traffic script: - ./blue-green-switch.sh blue green when: manual environment: name: production only: - main cleanup-blue: stage: cleanup script: - kubectl scale deployment myapp-blue --replicas=1 when: manual ``` Rollback procedure: ```bash #!/bin/bash # Quick rollback kubectl patch service myapp -p '{"spec":{"selector":{"version":"blue"}}}' echo "Rolled back to blue" ``` Monitoring during switch: ```python import requests import time def monitor_switch(environment, duration=300): metrics = ['error_rate', 'latency_p95', 'throughput'] start = time.time() while time.time() - start < duration: for metric in metrics: value = get_metric(environment, metric) if is_anomaly(metric, value): print(f"Anomaly detected: {metric}={value}") rollback() return False time.sleep(10) return True ``` Best practices: test rollback procedures regularly, automate everything, implement health checks, monitor business metrics not just technical, use gradual switch (weighted routing) for additional safety, maintain backward compatible migrations, document database migration strategy, implement automated rollback on anomalies, keep Blue running for configured time after switch, use feature flags for additional safety layer. Understanding Blue-Green enables zero-downtime deployments with instant rollback capability.

Uber CI/CD Pipelines Interview Questions | Preplance | Preplance

Master Interviews Anywhere, Anytime

Uber CI/CD Pipelines interview questions

Quick overview

1. Explain Gradle build system including build.gradle syntax, dependency management, tasks, multi-project builds, and performance optimization techniques.

Continue your preparation

2. Explain npm package management, scripts, versioning, and CI/CD integration. Include npm vs yarn, lock files, and security practices.

3. Explain artifact repository management using Nexus or Artifactory. Include repository types, proxy caching, artifact publishing, promotion workflows, and CI/CD integration.

4. Explain Docker multi-stage builds for optimizing images. Include build strategies, layer caching, security considerations, and CI/CD integration.

5. Design a comprehensive continuous testing strategy for CI/CD. Include test types, execution frequency, quality gates, and feedback mechanisms.

6. Explain TDD and BDD practices in CI/CD. Include Red-Green-Refactor cycle, Gherkin syntax, automation strategies, and integration with pipelines.

7. Explain test data management strategies including data generation, test fixtures, database seeding, and data privacy considerations in CI/CD.

8. Explain Canary release implementation including traffic routing, metrics monitoring, automated promotion/rollback, and integration with service mesh.

9. Explain feature flag systems including implementation patterns, targeting rules, A/B testing integration, and lifecycle management. Include examples with LaunchDarkly or custom implementations.

10. Design comprehensive environment management strategy including environment types, configuration management, secrets handling, and environment parity.

11. Explain Maven project structure, lifecycle, dependency management, and plugins. Include pom.xml configuration, repository management, and CI/CD integration best practices.

12. Explain Blue-Green deployment implementation including infrastructure setup, traffic switching, database considerations, rollback procedures, and CI/CD integration.

Master Interviews
Anywhere, Anytime