Dev + Ops = Delivery and support of software
- Dev and Ops work closely together
- Use of automation
- MonitoringInfrastructure (like use of containers / docker)Frequent ReleasesQuick testing
- Creates predictability and consistency (a delivery every 30 days)
- Define what DONE means
- Works in smaller chunks prioritizes the backlog
TFS and Team
Services are nearly Identical
- Version Control
- Project Management
- Scrum, agile
- Defect tracking
- QA Testing / Test Case management
TFVC (Team Foundation Version Control) vs Git
Centralized vs Distributed
Team Project is a container for all “stuff” for software development effort. Could be one team on one project, or multiple teams on multiple projects. Best practice is to keep fewest number of team projects.
Projects has a version control (tfvc, git) and process template (scrum, agile, cmmi). Team Projects can be created through the webui or vs.
Team Project Collections (TPC) = collection of team projects. Collections are all about storage and how they are stored in SQL server. Everything in the same TPC can share code and reference work items between Team Projects.
Best practice = use only one TPC. By default, use the DefaultCollection TPC. On the database, it is stored as Tfs_DefaultCollection.
Note that a Team Project may have one or many repositories.
Four types of Work in IT
- Business Projects (makes money)
- Internal IT Projects (not make money but still important)
- Unplanned Work
- Untracked work
- Work not tracked in same way
- Hidden work
- Unplanned work
- Drop everything and fix work
Things that slow you down
- Everything is “In Progress”
- Constraints / Bottlenecks
- The more you multitask, the more waste there is.
Working without multitasking in teams may mean that some members will occasionally be under-utilized, but the team overall will work faster due to a higher focus. This leads to continuous delivery.
Theory of Constraints
Having a team member that is overly busy and requires items to wait before they can address it can cause exponential Wait Time for the whole team and project. Wait Time = busy time / idle time
Theory of Constraint = removing the constraints will increase performance speed significantly
- Identify the constraint
- Exploit the constraint (make sure they do work right the first time)
- Subordinate all other activities to the constraint (avoid giving constraint more than can handle)
- Elevate the constraint to new levels
- Find the next constraint
Planning and Tracking Your Teams Work
Scrum and Kanban
Product Backlog Item (PBI)
Feature = Epic
Backlog Item (PBI) = Story
Add a pbi to a feature by dragging and drop it into the feature.
Each PBI has an effort field should use Story Points (1,2,4, etc)
Forecasting and Velocity
Velocity = how many story points can be burned down in a sprint. The velocity graph is shown on the top right of page.
Turn on Forecast View to see the forecast:
Once the velocity value is established, TFS will automatically apply it to forecast (if turned on above) and show in which sprint each of the PBI will be resolved:
Drag and drop PBI into the sprint. You can see it in the sprint by the column value:
Set the Sprint start and end dates.
How much work each team member can contribute to.
PBI can be set to each individual member and youll see how much that that member can take based on their capacity. You can also see the overall team capacity and the hours estimated for the overall sprint.
Customize styles (highlights, colors, etc)
Customize fields Burndown Chart
Add/Remove widgets. Edit widgets. Everything is tile based so you can set the location and size of each widget. Can also add new dashboards
Can also create widgets that show different query results. Queries can be customized to pull whatever data needed. Queries can also be used to create charts. These charts can be added to the dashboard.
Unit Testing and DevOps
Unit test = code that never gets deployed but tests code that does get deployed. It verifies low level features or functions.
In visual studio create Unit Test projects.
Unit tests follow this structure
- Arrange = setup the test
- Act = run the test
- Assert = verify the test
Testing is Layered
QA Tests are manual (usually) done by people. QA is a limited resource. As such, this is most expensive. The Unit Tests are cheap and should catch a majority of the issues. So focus on having good Unit Tests.
In DevOps, we try to skip the QA step as much as possible. QA is expensive and causes slow down (is a constraint). So instead focusing on unit tests will help speed up the process.
The more that Testing becomes automated, the actual QA testing actually changes its paradigm. Instead of doing test cases (which can be automated), they can do exploratory testing. This is more valuable as it goes beyond the original design and really checks the application in many different/new angles.
Automating Builds and Deployments
Benefits of automation
Solves the works on my box problem the following are addressed:
- Integration issues
- Code differences
- Version issues
The slight differences can accumulate to be significant in production and make it difficult to see whats wrong
The integration gives bottom line answer for Is the build broken?
- Build check
- Unit Test check
- Gives frequent deployments
- Problems can be caught quickly
- Users can test features quickly
Integration becomes less painful since constantly integrating
Two different types of builds in TFS
- All Build Definitions
Create a new build definition
- Xamarin (iOS, Android)
Can build from a remote repo
Every build gets a build ID, console, logs, results
Can view the Artifacts which are the resulting files from the build:
TFS runs unit tests. It is configured in the Visual Studio Test section of the build configuration. Give it a location to the test assembly. The assembly file should have the word test in it:
Note that if you have different tests (like unit test and integration test), make sure to specific those assembly names. The Run in Parallel = does multithreaded execution of unit tests (makes it faster but make sure its ok to use multithreads).
The Code Coverage Enabled will show how much of the code base is tested in the build results:
Want to keep this number somewhat high.
How a build is triggered. Can setup CI here. Can also do scheduled builds. The CI option means to run build whenever a change is commited to the set branch.
Can see build results through Team Explorer on Visual Studio. On the build definitons go to Options and can create auto generation of a ticket on build failure. Have it assigned to whomever did the last checkin.
Can also create issue tickets when a unit test fails. This can be done manually.
Agents do the build and can have custom capabilities
This can be configured in the Manage Project agents are defined at the Team Project Collection level
Agents have different capabilities. Custom capabililties can be added.
Then from the build definitions, can create demands that check for some of the agent capabilities. Based on what agents can meet those build demands, it will use that agent.
In the build definition, add a Visual Studio Test step. Notice the step order is controlled by this list
Look at the sample build script on site: deploy-to-sql-server.ps1
Things to be done in the build definiton
- Create directory on web server
- Copy code to web server
- Create App in IIS
- Modify the web.config
In the build definition, look at the Build
The following command will publish to the directory
This will drop all the deploy files in the for-deploy folder
To deploy those files to IIS, run following script.
We also want to update the connection on deploy. This can be done by have a Command Line step.
Under the build vairables, can also add the following connection string information
The script being called will now edit the web.config with the variables set above.
Lastly we want to deploy all the files from the build to the IIS server. This is another copy files step
Last step is to have IIS run a powershell script. The step is a PowerShell on Target Machines. You need to credentials on server to run this on that server.
DevOps blurs the line between Dev and Ops. DevOps allows developers to do some of the QA tests. Some of the test plans should be defined early so that developers can run them during their work. Use Microsoft Test Manager.
In TFS go to Test
There are different types of test cases that can be created within a test plan.
Requirement based suite creates test cases by a backlog item / story. In the test case, add information about the steps for the test.
Another way to enter test cases is through the grid, which is kind of a bulk entry
Can also test case parameters, which may include test data that is to be used.
To run the tests, right click on the test case and select run
Example of how a QA may run the test manually. They have both the test case list and the actual application.
From the test steps, if something fails, the QA may create a bug item right then. (link above).
Example of chart that summarizes all the test cases
MTM has a few more features that is missing on the web interface.
The following test types can be automated through TFS
UI tests are somewhat difficult to create as you are trying to work with the tool to make a sequence of actions happen. This sequence often have a lot of exceptional cases, which makes it difficult to write and can become a maintenance problem over time. UI automation tests should be used sparingly. Unit tests have far better ROI than UI tests.
automation tests are most difficult to maintain so this should be the fewest tests make them focused on specific items and not across the board. Some good judgement needed up front to determine what UI tests will be automated.
The automation UI tests will flow through the test cases and take screen shots: