TFS 2018 On-Prem Build Badges

Build Badges are a great way to communicate the build status of a given build for a project. Having this information quickly available to developers and project related staff is priceless. This can be stuffed in your README.md and displayed on the project home in TFS.

Read More

The Patterns Emerge

There are a number of patterns that reveal themselves to us daily. The sun rising and setting; the moon exposing itself to the tides below. There is a variance of change depending on the time of the year, month or day. Over time you if you keep track of it; the pattern will emerge. The same truth is applied to software development; over time if you keep track of the changes (success or failure) the pattern will emerge. I love anti-patterns; I love to learn about them in the software world. The world that I am interacting with; I also love to find the patterns that are around us. What commonality does this issue have to similar issues we have had? Some of my favorite anti-patterns are: the golden hammer, NIH (not invented here), and spaghetti code. Not to say that I enjoy these anti-patterns, but that the causation of why these occur. If you keep track of them, i.e. documentation, you will be better equipped to deal with them.

Read More

Self-Testing Development

comments suggest edit

Testing is a hard part of software development. One of the hardest aspects of development is testing code/features that you have created. It is easy to put the blinders up and write to the spec. Insider knowledge of the system probably plays a role in this difficulty. Seeing a system through user eyes is nearly impossible, but to get close you need to decouple yourself from the code.

Discipling yourself to test your own code and finding your own bugs is a difficult task. It is possible. Being a part of a code review process in which the code reviewer(s) look at code and possible bugs has made me a better developer. You will never find all of the bugs in an application; it takes a team, users, and time. The more bugs you find earlier the more reliable and usable the code will be.

Testing while you go helps too. Think of a fringe case? Go ahead write it down. Write a test for it. Do something.

The ability to look at your own code objectively is something I am continually trying to improve at. Catch bugs sooner. Make your code better sooner.

You are not your code

Refine.

You are not your code

Why would the user do x / y ?

They will. Many many many times.

Sometimes I click randomly on everything multiple times just to see what will happen. Curiosity. Users have curiosity with new features and will push them to their limits. An in-depth UAT will definitely find a number of bugs / issues. UAT is important because users will more easily accept tested code versus bug filled applications.

Here is the typical development process that I have had success with.

  • Development / Self-Test
  • Self-Test
  • QA
  • Code Review
  • If Large Changes? QA Again
  • UAT
  • Deployment
Read More

TFS, Git, Pull Requests and Code Reviews

comments suggest edit
"Change is the only constant in life." - Heraclitus

I have been using Team Foundation Server for a few years now in my day job.  Side jobs have also used TFS from time to time.  Leveraging GIT and the pull requests to control code reviews has definitely improved my code and the code of my fellow developers.

Communication is hard.  Developing software is hard.  Communicating and developing software is harder.

The ability to feature branch and merge to different environments to kick off automated builds gives a developer such a deeper look in the happenings of their code base.  It improves the ability for multiple developers to work on a code base and have their code work and not wait on someone else to commit.  The merge is easily the best part of Git in the .NET developer world.  In the past I've used SVN and the merging was always complicated and clunky.  Feature branching is built-in to the core of Git and TFS shines with Git as the code management feature.

The gate keeping of pull requests to a production environment helps stop bad code from getting into the wild.  It is not a silver bullet, but having more eyes on code is always a good function.  Utilizing the code reviewer for basic QA services, is a time consuming activity, but the quality of code that is delivered is almost always better.  The ability to compare branches against staging, production or other environment ensures everyone is keeping up-to-date.

Speaking of code reviews; it is a function that I believe is critical to deliver software.  It is a safety net for a number of different areas:

  • Reliability
  • Maintainability
  • Quality
  • Communication
  • Usability

Reliability - Fix those easy bugs that get through code.  Simple bugs: order of operations bugs.  Typos.

Maintainability - Will someone else understand the code?  Is the developer making it too hard?

Quality - Does the developer have the latest version?  Has the developer pushed the code to testing / QA?

Communication - Setting up notifications on pull requests approvals or denials.  Automated push notifications to your master branch or testing environments.  These type of communications ensure teamwork.

Usability - Does the code mean UI usability / code standards?  Is the UI logically?  Are the orders of operation correct?  What happens when you run them incorrectly?

Read More

Automating ASP.NET Deployments with Jenkins

comments suggest edit

Deploying ASP.NET web applications is a breeze with Jenkins and can really improve continuous integration/testing environment for UAT.  It is also possible to do production deployments with scheduled builds.

In your ASP.NET setup > manage your publish profiles.

2015-09-15 10_13_11-Publish Web

Here we have two profile Production and Staging.  This gives us a Development environment (localhost), Staging Test (UAT environment), and Production environment.  The profiles both point to shares where our web applications are stored.

From the Visual Studio aspect this is the only piece we will need - except for the entire project.

Jenkins will need to hook into your Version Control Management system to know when to do builds.

Here's a typical CI staging hook:

2015-09-15 10_18_36-Helpdesk_Staging Config [Jenkins] - Internet Explorer

In this scenario we are using SVN (SubVersioN) to know when to kick off our build.

2015-09-15 10_19_32-Helpdesk_Staging Config [Jenkins] - Internet Explorer

We will poll for any new changes every 5 minutes.

2015-09-15 10_22_30-Helpdesk_Staging Config [Jenkins] - Internet Explorer

With our staging profile built and in our VCS we can build with that configuration with MS Build.

This is a simple scenario with Jenkins to build your ASP.NET web applications quickly.

Read More