Showing posts with label Source control. Show all posts
Showing posts with label Source control. Show all posts

Tuesday 13 February 2018

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.


Tuesday 23 January 2018

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

Saturday 31 July 2010

Best Practice Sharepoint 2010 coding tips

1.> SharePoint Dispose Checker Tool - Run the SP Dispose Checker Tool on all custom code you write.
SPSite & SPWeb object has a big load and we need to ensure dispose is always called. 2 easiest ways to ensure Site and web objects are always disposed are shown below:
SPSite site;
try
{
site = new SPSite("http://demo1"); // Create the SPSite object
...
}
finally
{
if (site != null) // Check if the SPSite object exists
{
site.Dispose(); // Clean up the SPSite object as it has not be disposed of
}
}

Alternatively I prefer to use using statements
using (SPSite site = new SPSite(http://demo1/))
{

.... // SPSite.Dispose method will be called always
}
Run the SPDisposeCheck tool on all code before deploying outside of you development environment, this can be automated into VS 2010.
2.> Have at least 3 environments i.e. don't send code from the developers machine straight into production. Sandboxed solutions alleviates this risk to some degree but use a UAT, pre-prod, QA environment. Your deployment environment must mimic production as closely as possible i.e. ensure there is a separate SQL DB, all versions of software are identical, load balancing is setup. Have documented change control. Try perform changes through scripts not manual changes if possible. Web.config changes need to be replicated to all servers on the farm so doing the change manually is not the best option. Change the web.config via code to ensure it is done through the configuration database so they are changed on all web.config's in the farm.
3.> Error handling, catch errors as specifically as possible, die gracefully and appropriately, log the errors, check the production error logs periodically.
4.> Deploy code using wsp solutions. Ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment. Implement CAS, deploy to bins if possible and apply CAS security policies to custom coding. Perform peer code reviews, it ensures coding standards are being followed, developers learn from each other, bugs are often picked up pre-testing and it increases team members knowledge that reduces maintenance costs.
5.> Develop using source control no matter how smal the dev project is. Preferably TFS 2010 but VSS 2005 is even fine, failing this use CVS, IMB/rationals ClearCase for source control. Also have bug tracking with TFS the integration is excellent between the bugs and the source control. I.e. use TFS if possible.
6.> SharePoint projects are often very good candidates to SCRUM or other agile methodologies. Use them if it's appropriate. Traditional formal SDLC / waterfall approaches tend to work well on the larger SharePoint projects.
7.> Use the developer dashboard.
8.> Unit testing - don't test SharePoints API, test your custom code. In MOSS Type Mock isolator was a great product for SharePoint I presume this is still the way to go. Andrew Woodward is a good blogger on SP unit testing.

Tuesday 29 June 2010

SharePoint 2010 using VS 2010 and Visual Source Safe 2005

Overview: Client is implementing SP 2010, they don't have TFS and the source control is Visual Source Safe (VSS) 2005.
Steps to integrate VS2010 into VSS 2005:
  • Install the VSS client on your development server/environment;
  • Open the VSS explorer and add the project (Subsequent developers need to locate the file and download a copy) and set the working directory if pulling the project;

  • Open VS2010, select Tools > Options > Source Control > Plug-in Selection > Change the source control to "Microsoft Visual SourceSafe";


  • I prefer to hold my solution file locally and pull my projects however a lot of architects prefer to keep the solution in Source Control. Open the solution in VS2010 and you should be ready to run.
  • Tip: If you projects won't deploy click on the project and look at the "Site Url", this gets cleared down. Enter you local development server url i.e. http://demo1.app.dev/