In software engineering, a fluent interface is a method for designing object oriented APIs based extensively on method chaining with the goal of making the readability of the source code close to that of ordinary written prose, essentially creating a domain-specific language within the interface [Wiki].
For example for Stablishing a connection to a database and fetch orders data in a table with common developmment.
var connection = new SqlConnection(connectionString);
SqlCommand command = connection.CreateCommand();
command.CommandType = CommandType.Text;
command.CommandText = "SELECT * FROM Orders WHERE OrderId = @OrderId ";
SqlParameter parameter = command.CreateParameter();
parameter.DbType = DbType.Int32;
parameter.ParameterName = "@OrderId ";
parameter.Value = inputOrderId;
var adapter = new SqlDataAdapter();
adapter.SelectCommand = command;
var table = new DataTable();
connection.Open();
adapter.Fill(table);
connection.Close();
connection.Dispose();
command.Dispose();
var orders = new List<Order>();
foreach (DataRow row in table.Rows)
{
var order = new Order
{
OrderId = (int)row["OrderId"],
OrderedByName = (string)row["OrderedByName"],
DeliveryAddress = (string)row["DeliveryAddress"]
};
orders.Add(order);
}
But of course it can be shorter with using of Fluen Interface
List<Order> Orders= new SqlQuery(connectionString)
.SetCommandText("SELECT * FROM Orders WHERE OrderId = @OrderId")
.AddParameter("@OrderId", OrderId, DbType.Int32)
.GetDataTable()
.GetList<Order>();
in large organizations it’s so important that not all the colleagues who are working together on a project to be able to release/ deploy the product in production environment.
There must be always a check list to get ready for deploying in production. Nowadays this check list is called continuous integration/deploy (CI/CD).
The check list before deploy the product on production environment
Therefore the project team try to grant permission according to the responsibilities and tasks or each colleagues to team. On of the tools which we can use to develop a project with the agile method is Azure DevOps.
There is also possible to assign built-in Access Level and Security Group to each member of team as explained in follows.
The users/ members in Azure DevOps always have an assigned DevOps Group and Access Level.
DevOps Built-in Access Level
Access Level defines the Azure DevOps Features that a user or group can use.
Access Levels
Description
Basic
Basic supports full access to all Azure DevOps Board features
Stakeholders
Provides partial support for viewing and modifying work items but not using all features.
Visual Studio Subscriber
Free access to a limited set of features.
DevOps built-in security Groups
Security Groups define what users of groups can do with each Azure DevOps features.
Azure DevOps has mainly two different level of built-in groups [Microsoft Doc]:
Collection-Level
Project-Level
The Team Administrator is the person who can grant permissions to specific features.
Note
Your Text Here
Project-Level Security Groups
Each project contains the following built-in groups:
Permission to view project information, the code base, work items, and other artifacts but not modify them.
Project Contributors
Permission to contribute fully to the project code base and work item tracking. They cannot manage or administrator resources.
Project Administrators
Permission to administer all aspects of teams and project. Although they cannot create team projects.
Combination Matrix of the Access Level and Security Group
in Project-Level
DevOps Security Groups
Access Levels
Description
Project Readers
Stakeholder
–
Project Readers
Basic
–
Project Readers
Visual Studio subscriber
–
Project Contributors
Stakeholder
Managers or users who don’t actively contribute to the code base but want to check project status or provide direction, feedback, feature ideas, and business alignment to a team.
Project Contributors
Basic
Full-time workers who contribute to the code base or manage project.
Project Contributors
Visual Studio subscriber
Code base contribution
Project Administrators
Stakeholder
The users, who are tasked to managing project resources. If them also need to contribute to the code base, then the Basic Access Level must be assigned to them.
Project Administrators
Basic
Managing project resources + Code base contribution
Project Administrators
Visual Studio subscriber
Code base contribution
Combination Matrix of the Access Level and Security Group
in Collection-Level
DevOps Security Groups
Access Levels
Description
Project Collection Administrators
Stakeholders
The users, who are tasked with managing organization or collection resources and if they need to be contributed to the code base then they must be assigned to Basic Access Level.
Project Collection Administrators
Basic
–
Project Collection Administrators
Visual Studio Subscriber
–
Azure DevOps Levels
DevOps can be configured at different levels:
Organization/Collection
Project
Object
The focus of this document is Project-Level and object-Level.
Object-Level Groups
Managing the permission on Git branches.
Using Azure ADD Group in Azure DevOps
For managing the
users the Azure DevOps can be connected to Azure AD. The AAD Groups can be used
in Azure DevOps as well. But the Active directory Group hierarchy is not usable
in Azure DevOps. It means the sub groups will not inherit the access level and
permission group of their parent group.
Each AAD parent
and sub group must be added separately to Azure DevOps and an Access Level and
a Permission Group must be assigned to each one separately them.
The users which
are assigned to the same AAD Group will have the same Access Level and
Permission Group, which has been assigned to this AAD group in Azure DevOps.
Note
Your Text Here
The Advantage is:
A newly
added user to AAD Group can login to Azure DevOps and there is no need for
additional configuration.