By 
Azure DevOps is widely used by development and IT teams to manage code, track work, and automate deployments. But before you can start using pipelines, repositories, or boards, you must create an Azure DevOps project.
If you’re new to Azure DevOps, this step can feel small but it’s one of the most important decisions you’ll make. Project settings affect security, workflows, and how your team works long term.
In this guide, you’ll learn how to create a project in Azure DevOps step by step, understand each option, and follow best practices used by real-world teams.
What Is an Azure DevOps Project?
An Azure DevOps project is a logical container that organizes all DevOps resources for a specific product, application, or team.
Each project can include:
- Azure Boards for planning and tracking work
- Azure Repos for source control
- Azure Pipelines for CI/CD automation
- Azure Test Plans for testing
- Azure Artifacts for package management
Most teams create one project per application or product to keep things clean and manageable.
Azure DevOps projects also act as the foundation for CI/CD automation using Azure Pipelines, which we explain in detail in our Azure DevOps CI/CD Pipeline: Azure Pipelines Overview, Architecture, and Best Practices guide.
Prerequisites Before Creating a Project in Azure DevOps
Before creating a project, make sure the following are already in place.
1. Azure DevOps Organization
Projects live inside an Azure DevOps organization. If you don’t have one yet, you must create it first.
If you’re new to Azure DevOps, start by setting up an organization first. Follow our step-by-step guide on How to create organization in Azure DevOps before continuing.
2. Required Permissions
You must have one of these permissions:
- Organization Owner
- Project Collection Administrator
- “Create new projects” permission enabled
If you’re working in a corporate environment, your DevOps admin may need to grant access.
Step-by-Step: How to Create a Project in Azure DevOps
Step 1: Sign in to Azure DevOps
Sign in to your Azure DevOps organization using your Microsoft account or work account. You’ll land on the organization home page where existing projects are listed.
Step 2: Select “New Project”
On the organization homepage:
-
Click New Project (top-right corner)
This opens the project creation panel.
Step 3: Enter Project Name and Description
Project Name
Choose a clear and descriptive name. This name cannot be changed later.
Good examples:
- Customer-Portal
- HR-Automation
- Payments-API
Avoid:
- Test
- Demo
- Project1
Description (Recommended)
Add a short explanation of the project’s purpose. This helps future team members understand the context quickly.
Step 4: Choose Project Visibility
You have two options:
Private (Recommended)
- Only authorized users can access the project
- Best for enterprise and internal applications
Public
- Visible to anyone on the internet
- Suitable for open-source projects
Most teams should select Private.
Step 5: Select Version Control
Azure DevOps offers two version control systems.
Git (Recommended)
-
Distributed version control
-
Industry standard
-
Works seamlessly with Azure Pipelines
TFVC
-
Centralized version control
-
Mostly used in legacy environments
For modern development, Git is the best choice.
Step 6: Select Work Item Process
This choice determines how work items are structured.
Available options:
- Basic – Simple and beginner-friendly
- Agile – Flexible and widely used
- Scrum – Sprint-focused framework
- CMMI – Structured and compliance-driven
Best practice:
- Beginners: Basic or Agile
- Scrum teams: Scrum
- Regulated industries: CMMI
Step 7: Create the Project
Click Create.
Azure DevOps provisions:
- A Git repository
- Boards and work items
- Pipeline capabilities
- Default permissions
This usually takes less than a minute.
What Happens After the Project Is Created?
Once your project is ready, you can begin actual DevOps work.
Default Git Repository
A Git repo is created automatically. You can:
- Clone it locally
- Push existing code
- Create branches and pull requests
Boards and Planning
You can start creating:
- User stories
- Tasks
- Bugs
- Sprints and backlogs
CI/CD Enablement
Most teams move next to automation.
After setting up repositories, teams typically configure build and release automation using Azure Pipelines to support CI/CD workflows.
Azure DevOps Project Settings Explained (Recommended Configuration)
After creating a project, the next important step is reviewing Project Settings. These settings control access, repositories, pipelines, boards, and integrations. Configuring them correctly at the beginning helps avoid security issues and rework later.
You can access Project Settings by selecting Project Settings in the bottom-left corner of your Azure DevOps project.
General Section
Overview
Purpose
Shows basic project information, including:
- Project name
- Description
- Visibility (Public or Private)
- Organization
Recommended configuration
- Keep the project Private for internal or enterprise workloads
- Add a clear description that explains the project purpose
- Avoid changing project visibility after creation unless required
Why it matters
This information helps new team members and stakeholders understand the scope of the project quickly.
Permissions
Purpose
Controls who can access and manage the project.
Built-in security groups include:
- Project Administrators
- Contributors
- Readers
Recommended configuration
- Limit Project Administrators to a small group (typically one to three people)
- Assign developers to the Contributors group
- Use the Readers group for stakeholders or auditors
- Manage access using groups instead of individual users
Why it matters
Over-permissioning is one of the most common security risks in Azure DevOps projects.
Teams
Purpose
Defines how work is organized and tracked in Azure Boards.
Each team can have:
- Its own backlog
- Sprint configuration
- Area paths
Recommended configuration
- Use the default team for small projects
- Create additional teams only when work needs to be clearly separated
- Configure sprint duration correctly (for example, two-week or three-week sprints)
Why it matters
Teams directly affect how backlogs, boards, and sprint planning work.
Other Settings in the General Section
The General section also includes a few additional settings that teams often configure later, once the project is actively in use.
Notifications
Purpose
Controls project-level notifications such as pull request updates, build failures, and work item changes.
Recommendation
- Use default notifications initially
- Encourage users to configure personal notifications instead of global ones
- Avoid enabling too many project-wide alerts to reduce noise
When to revisit
When the team grows or when critical alerts are being missed.
Service Hooks
Purpose
Allows Azure DevOps to send events to external systems such as:
- Slack or Microsoft Teams
- ServiceNow
- Webhooks and custom APIs
Recommendation
- Configure service hooks only when there is a clear integration need
- Restrict who can create and manage service hooks
- Document all active hooks
When to revisit
When integrating Azure DevOps with monitoring, ITSM, or chat tools.
Dashboards
Purpose
Provides visual insights into project progress using widgets and charts.
Recommendation
- Use dashboards for high-level visibility only
- Create separate dashboards for teams and stakeholders
- Avoid overcrowding dashboards with too many widgets
When to revisit
After sprints are running and work items exist.
Repos Section
Repositories
Purpose
Manages Git repositories within the project.
Recommended configuration
- Use Git as the version control system
- Follow a consistent repository naming convention
- Use one repository per application when possible
Example repository names:
Project Repos settings in Azure DevOps
Branch Policies
Purpose
Protects critical branches such as main or develop.
Recommended configuration
- Require pull requests for the main branch
- Require at least one or two reviewers
- Enable build validation
- Prevent direct pushes to protected branches
Why it matters
Branch policies help prevent broken or unreviewed code from reaching shared branches.
Pipelines Section
Settings
Purpose
Controls pipeline creation and execution behavior.
Recommended configuration
- Use YAML pipelines instead of classic pipelines
- Restrict pipeline creation to trusted users
- Store pipeline YAML files in the same repository as the application code
Why it matters
YAML pipelines provide better versioning, visibility, and scalability.
Service Connections
Purpose
Defines how Azure DevOps connects to external services such as Azure subscriptions, container registries, or GitHub.
Recommended configuration
- Use Azure Resource Manager service connections
- Authenticate using service principals
- Scope access to only the required subscriptions or resources
- Avoid using personal accounts
Why it matters
Service connections are a key security boundary in Azure DevOps.
Boards Section
Project Configuration
Purpose
Controls work item behavior, area paths, and iteration paths.
Recommended configuration
- Use a single area path for small teams
- Create multiple area paths only when teams or products need separation
- Define iteration paths (sprints) in advance
Process
Purpose
Defines the work item types and workflow used by the project.
Recommended configuration
- Basic or Agile for beginners and small teams
- Scrum for teams following Scrum practices
- CMMI for regulated or compliance-heavy environments
Important note
Changing the process later requires migration and should be avoided if possible.
Test Plans Section
Settings
Purpose
Controls manual and exploratory testing features.
Recommended configuration
- Enable Test Plans only if your team performs manual testing
- Use exploratory testing mainly for user acceptance testing scenarios
- Skip Test Plans if your team relies fully on automated tests
Why Project Settings Deserve Attention
Many Azure DevOps issues stem from poor initial configuration rather than tooling limitations. Spending time reviewing Project Settings early helps ensure security, clarity, and scalability as the project grows.
Real-World Use Cases
Web Application Teams
- One project per application
- Separate repos for frontend and backend
- CI/CD pipelines for each environment
Cloud and Infrastructure Teams
- Store IaC templates (Bicep/Terraform)
- Automate deployments
- Control approvals via pipelines
Internal Business Automation
- PowerShell and Power Platform solutions
- Version control and governance
- Centralized DevOps workflows
Best Practices for Azure DevOps Projects
- Create one project per product or application
- Use consistent naming standards
- Limit Project Administrator access
- Configure permissions early
- Protect main branches with policies
- Align pipelines with your branching strategy
Well-structured projects scale far better as teams grow.
Common Mistakes to Avoid
- Creating too many unrelated projects
- Choosing the wrong work item process
- Giving everyone admin access
- Ignoring documentation and descriptions
- Delaying CI/CD setup
Frequently Asked Questions
What is an Azure DevOps project?
It’s a container that holds repositories, pipelines, work items, and test plans for a specific team or application.
Do I need a project before creating pipelines?
Yes. Pipelines must exist inside a project.
Should I create multiple projects or one large project?
Microsoft generally recommends one project per product or application.
Conclusion and Next Steps
Creating a project in Azure DevOps is the first and most important step toward building a strong DevOps foundation. When done correctly, it makes collaboration easier, improves security, and sets you up for scalable CI/CD.
Recommended next steps:
- Add team members and permissions
- Push code to the Git repository
- Configure branch policies
- Set up CI/CD pipelines
- Align workflows with your team process
Once your project is ready, automation and delivery become much easier.
About Post Author
