GIT Intro

Overview: Git is is very popular and it is similar to existing version control systems.  The key is to be able to work on multiple branches that you can go to at any point.

Let's get started..

Start a new Git repository (repo) - all folders created under the main git folder are part of the repository. Any changes are kept track of and all change history is recorded.  The new repo has a default main branch created automatically.  To create a new repo use the syntax:

>git init

There are files you don't want to keep track of in the repo, so use the .gitignore files or folders to skip specific files from being tracked int he repo.

Once you are writing code, you get a Git local staging area.  -A means All files and folders

>git add -A

Now you make changes in your staging environment via your IDE, and need to add it back to the default "Main" branch.

Create a repo, add code, change code and commit to the branch.

This is a fantastic simple illustration to quickly understand Git.

GitHub is Git hosted (centrally hosted instances, bought by Microsoft circa 2018 but still open source, https://github.com), the developer clones the GitHub repository and works using a distributed source control.  You can host yourself but has great integration with Azure DevOps.   You can also replace the central GitHub with Azure DevOps (Git).

• Git ignore files, tells source control not to include certain file types
• Tags for a specific point in time.  Like labels in TFS/Azure DevOps
• Pull request (PR) - dev made change, and wants to push the code into main branch, someone else generally approves and the code is pulled into the main (Working Directory) branch (depends on branching strategy)
• Developer normally branches of Main branch using a cloned copy on local dev env.  The Developer does changes, then does a PR, the PR if approved gets approved it gets merged into Main (automatically or manually per config), Main branch has the latest code and the developer can delete their cloned branch.
• GitHub Enterprise allows integration with Microsoft Teams (sounds amazing)
• GitHub Codespaces - Instead of local dev, it allows dev using a browser.  Competes with Microsoft's Dev Box (spins up dev env that is browser accessible).  Microsoft Dev Box iGB VM's to choose from, the 16GB, has 4 vCPU's.  Only bills when DevBox is running but the storage used is continuous.  If left on/max monthly cost, it would cost about £370, if well managed i.e. turned off on weekend and overnight but used for roughly 8 hrs a day cost would be around £85 for a month.  All dev licences are included.  Pls check with Ms this is my understanding.

DevOps has morphed into DevSecOps (Development, Security, Operations) - same team responsible for all the roles.  Continuously ensure security built in, call shifting left so it is not tact on at the end of the project.  Includes monitoring and auditing.  Git like other source control systems assists in DevSecOps.

Basic Branching Strategy for TFS and GIT

• The main difference between standard TFS branching strategy is that you branch more often for shorter time periods and check in small code change units into the "Development" branch.
• Delete the black line once the feature is complete and checked back into the Development branch.  Can easily start a new functional local GIT branch to amend the next feature.

Note: Easy to also grab a GIT local branch from the Main branch (inline with you production code base), make changes and then when checked back in they hot-fix goes into both the Main and Development code branches.

Choosing the branching strategy is normally: Release, patch or feature driven.

Visual Studio 2019, Commit code to GIT repository

DevOps Tooling

DevOps Tooling Notes

DevOps Tooling is broken down into the following areas, note the tools often overlap in function.  The list is not exhaustive but these are the more common tools I have come across.

1. Version Control: TFS, Git, SVN, ...
2. Bug Tracking: ServiceNow, Jira, ZenDesk
3. Continuous Testing: Selenium, Jasmin or Mocha or Unit.js (JavaScript testing), NUnit, Web Tests (Visual Studio), SpecFlow
4. Continuous Integration (CI): TeamCity, Jenkins, Azure DevOps (bigger) 
5. Configuration Management and Deployment:  Puppet, Chef, ANSIBLE, SALT  (all installed on Linux, obviously work on Windows environments)
6. Containers: Docker, Kubernetes, Microsoft Containers. I think the Azure AKS is pretty much containers for Azure now.
7. Other:  PowerShell, VMWare, HyperV

RESTful API Tooling

1. Swagger - awesome.  Swagger is a set of tools that help document, build and test your API  (Your API conforms to the OpenAPI specification or Swagger specification).  Great way to get a contract for users of the API early on.  Updated 2019/11/25:  Link to Swagger post
2. Swagger UI, Swagger Integrator,...
3. Apiary - UI to create an API and publish with mocks.  I prefer Swagger or on simple projects APIM.
4. API Management (APIM) - flexible Azure service for bring together multiple API securely.  Same as MuleSoft.  Can import OpenAPI's v2 or v3 to create a hosted API.  Can mock and built in test tool.
5. RAML is an alternative to Swagger and Apiary (never used)
6. Blueprint - API documentation tool.  Pretty simple and nice results.
7. Postman - send http requests to the API.  Postman is a REST client useful to check your API.  This is my main tool for testing, exploring REST based API's.  
8. SoapUI - if working with SOAP/XML.
9. Slate - API documentation - I always use OAS/OpenAPI/Swagger.
10. Fiddler - I'm old school and still love Fiddler and it's capabilities.  Fiddler is a great HTTP debugger.  
11. BURP - an HTTP debugger to review traffic.  I've used BURP for security testing and it is great for API debugging.  
12. Charles is another HTTP debugger (never used).
13. cURL - Cmd line to test API's using HTTP, separate exe to run on Windows, Windows 10 has cURL built in.
14. Visual Studio
15. Wireshark - Over the years I have needed packet sniffing to fix issues and always go to Wireshark, I used the tool in the 90's but it had a different name.  Extremely useful for issues relating to firewalls, especially when an environment reacts differently to another working DTAP environment.
16. Tcpdump is another packet sniffer

Testing:
http://www.incyclesoftware.com/2014/02/executing-selenium-ui-tests-release-management/

More Info:
http://blog.sharepointsite.co.uk/2014/02/devops-and-sharepoint.html
http://www.networkworld.com/article/2172097/virtualization/puppet-vs--chef-vs--ansible-vs--salt.html
http://blog.sharepointsite.co.uk/2013/11/iac-presentation-for-sharepoint.html