In an older post on website performance using concatenating and minification I used the Ajax Minifier tool to do the work and used an MSBuild file to run that tool, now I use gulp which I find easier as it only needs a dependency on node and so can be separated out from the Visual Studio project itself and run outside the build cycle.

Gulp

When run in a CI/CD environment, the gulp file is processed before an actual build takes place, this is so that the AssemblyInfo.cs file can be amended with the version information. The gulp file can be broken down into 3 main parts; the version, concatenation and minification and the assembly version writing.

The default task is run initially which will then run the version task. The version task reads any parameters passed into the gulp runner, in this case it is looking for buildVersion and uses the yargs library. If it is undefined, then it is being run outside the CI environment and can default to 1.0.0.0. Then it performs the concatenation and minification of the styles using the gulp-concat and gulp-cssnano libraries. The resulting file is then written out to the public-assets/css directory which is where they are referenced from in the HTML view.The same process is taken for the JavaScript files except the gulp-uglify library is used to minify them.

Writing them to the public-assets/js and css directories allows the directories to be classed as static in IIS and so we can add addition headers such as expiry dates. Finally the same version number is passed to the assembly-info task which uses the gulp-dotnet-assembly-info library. This simply changes the AssemblyInfo.css file so when it is built, the assembly will have this version. Then when both JavaScript and css files are linked to in the HTML, the assembly version can be injected to the url.

 

TeamCity Integration

It is real easy to include a gulp task to TeamCity by creating a Build step to your pipeline and choosing the Command Line as the runner type.

tc

Then specify ‘Custom script’ from the drop down and enter your normal gulp command in the Custom script text area.

With my gulp script I specify a build version parameter which gets its value from the environment variable BUILD_NUMBER. This is the counter that the gulp build step generates when it is running. I use this value, inject it into the gulp script using the version task which is then used to name the css and JavaScript files. It also changes the AssemblyInfo.cs file to create a unique assembly version.

Happy coding

Foggy Software Development

Software development is one of those areas that it is important to find the fine line between too little specification and too much. One project I worked on recently for a client had tremendous success mainly due to good user story development and a good development team that could take those stories and run with them.
Thanks to:- https://www.flickr.com/photos/infomastern/

This was an agile shop that used the agile template in TFS but also used the vocabulary of scrum interchangeably. Nothing wrong with that, I believe there has to be a balance between adapting your process to your environment as opposed to changing your environment to fit the process especially in larger more traditional businesses. So they had sprints, sprint planning but also user stories as opposed to product backlog items. So six months into the project and all sprints were on the line of the burn-down chart, then things started to go wrong. The burn-down chart was way off with the resources we had at hand, the reason? Well we started to get user stories such as this:-

Story title: We need a different view of the data

Description: To do

Or

Story title: General printing

Description: To do

There isn't much you can do with these, but they were in the sprint. The more time a developer spends going to ask for clarification about a user story, the less effort they can put into acting on the story. The end result after all the backwards and forwards communication is an inaccurate burn-down which can lead to a demoralised team and possible infighting. Why were these in the sprint you may ask? Well for some unknown reason, management decided to take a more hands on approach to the project and so forced stories into sprints instead of the software development team deciding what resources were available to tackle the high priority stories. The stories had to be done in that sprint even if the resource was not enough to cover it. Add to that, the management only had a vague idea of what those stories were and possibly due to lack of time couldn't expand on their details.

So what is just enough information for a user story?

  • The product owners should define the features of the project.
  • The business analyst and business owners should define the user stories that lead to the features and describe the acceptance criteria to fulfil the user story.
  • The development team should create the tasks off the user stories that will fulfil the acceptance criteria and make the user story valid.
So there has to be enough information in the user story that will define the acceptance criteria at a minimum; the implementation details should be down to the development team. So what happened to the two user stories mentioned earlier? They eventually got removed from that sprint in to the next, and then in to the next after that. Finally they were broken down into smaller stories that were described better and then got implemented into the project.   Happy coding