Friday, 19 August 2016

More than just a build/release pipeline

You've setup your build server, have continuous integration/delivery. Setup your release service, have continuous deployment. Your team are following proper branching strategy. Good yeah?

However...

Monday, 1 August 2016

On premise CI/CD/CD with VSTFS2015 and IIS

Many clients I visit are still not on the cloud and are still not using VSTS (Visual Studio Team Services) online and Azure.

Meaning, they still have on premise infrastructure for their applications. Now, I don't want this blog post to turn into a defence of cloud (more specifically PaaS). Rather, I want to quickly show you how you can setup a CI/CD/CD  (Continuous Integration/Delivery/Deployment) delivery pipeline with an on-premise instance of VSTFS 2015 deploying to machines with IIS .

Basically, if you're still on premise! It's not an excuse to disregard DevOps practices!!

Monday, 18 July 2016

WHY the same place and time for your daily stand-up?

"we're all here, let's just have stand-up now"
"so-and-so isn't coming today, so let's have stand-up now"
"hey, I'll just come over there and we'll do stand-up there"

It seems so easy and innocent to simply change the time and place of stand-ups, especially when key people such as the PO or Scrum master may not be attending the meeting for the day. The reasons I recommend for not changing are:


Thursday, 21 January 2016

Lessons from a greenish-field project

As consultants most of our work involves either PoCs or going into brownfield projects. However, recently I had the opportunity to go into a greenfield project, and below are the lessons I learnt.

Don't over engineer

The stack that I was using was pretty standard. Entity Framework + MVC5. However, at the end of the project I found that the architecture that I have created was overly complicated when it need not be. Using an ORM such as Entity framework means that you already have a pretty solid data access layer in-place. What I had done was abstract this data access layer away from the business layer so that the business layer is not calling any Entity Framework code at all. I found this design to be too complicated, because the layer that abstracts EF was basically a wrapper that pipes into EF. Next time, I would simply call EF from my business tier. There is nothing wrong with this as EF already implements a repository pattern.