Search This Blog

Sunday, September 8, 2024

Q26-Q30

Q26: What you understand by DevSecOps?
Q27: Tell me how your current project is managing DevOps. Start from Code Check-in Phase?
Q28: How can you relate Azure Test Plan with Azure Test Pipeline. ?
Q29. Difference between Blue Green and Canary Deployment?
Q30: What are the various deployment strategies we have like Blue Green, Canary etc?

============================================================================================
Q26: What you understand by DevSecOps?

Answer:
As an azure DevSecOps it's our duty to ensure that Security is the shared responsibility of both Dev team and operations team. 
As a DevSecOps team, we must assure that our pipeline has all tests present init. 
eg
Unit test
Performance test
Vulnerability test can be done with Github CodeQL like SQL injection, XSS etc
Code Quality Check
Code Coverage

-- DevSecOps also must considere usage of 
>> Azure KeyVault for storing important information. 
>> Azure policies must be intact while deploying infra changes. 
>> use of selfhosted Agents for running pipeline. 

Pre deployment checks like all the instances/ Nodes where our application is going to host must be up and alive. 

============================================================================================
Q27: Tell me how your current project is managing DevOps. Start from Code Check-in Phase?

Answer:
Considering we scope the requirement as below structure

Epic > Features > User Stories > Tasks/ Sub Tasks/ Bugs

Below will be my branching strategy and its impact on DevOps pipeline. 

1. Master(Main) Branch. 
  • Purpose: Production-ready, stable code.
  • Deployment Target: Production environment.
  • Pipeline:
    • Fully automated CI/CD for release to production (manual approval gate before prod).
    • Protected branch: only merge via pull requests from Feature branches after successful validation.
2. Feature Branches
  • Naming: feature/<feature-name>
  • Lifecycle: Exists for the duration of the feature; deleted after merge into master.
  • Deployment Target: DEV / QA environments.
  • Pipeline:
    • Deployments to DEV/QA are triggered when Feature branches are updated (PR merges from User Story branches).
    • Useful for end-to-end feature testing or integration testing across multiple stories.
    • Why: This gives you an isolated integration layer for a feature, which may involve multiple user stories developed in parallel.

3. User Story Branches

  • Naming: story/<story-id>-<short-name> (e.g., story/US1234-add-currency-dropdown)
  • Lifecycle: Short-lived. Developer pushes their commits here; once the story is complete, a PR is raised to the Feature branch.
  • Pipeline:
    • Validation Pipeline runs automatically on PR:
      • Build
      • Unit tests
      • Code quality (SonarCloud)
      • Security / vulnerability scanning
      • Integration tests
      • Code coverage thresholds
      • Optional performance smoke tests
      • PR cannot be merged if validation fails.
      • Why: Keeps the integration layer clean and forces code quality gates before story completion.


============================================================================================
Q28: How can you relate Azure Test Plan with Azure Test Pipeline. ?

Answer:
Azure Test pipeline is nothing but a part of CICD pipeline. The logic of Test Pipeline could part of main pipeline or standalone pipeline.
During pipeline runs, automated tests get executed, and their results can be published back to Azure Test Plans

That’s the key connection: the pipeline runs the tests, and the test plans reflect the outcomes.

============================================================================================




============================================================================================
Q30: What are the various deployment strategies we have like Blue Green, Canary etc?

Answer:
Majorly 3

1. Blue Green -  Two identical environments (Blue = current, Green = new). Switch traffic instantly.
2. Canary - Gradual rollout to a small user subset, then expand if stable.
3. A B Testing - Split traffic between two versions to compare performance or UX.

============================================================================================

No comments:

Post a Comment

Q31-Q35