As expected there is a bunch of stuff being announced at //BUILD/.
Time to play
As expected there is a bunch of stuff being announced at //BUILD/.
Time to play
I've had this discussion a couple of times over the last number of years, and people tend to not believe me when I say that in the Agile world, we want to fail!
For emphasis I will repeat that : In the Agile world we want to fail
Let that sink in a bit…
OK, now that you think I am full of it and must not have a clue as to what I'm speaking about, lets continue.
Waterfall or Structured methodologies / processes
Let's take the example of a waterfall approach. We analyse the work, get to development and finally deliver the functionality. The only problem is that this could take anywhere from months to years to get the first working software out there.. And now the customer or client can look at it and decide that this is not what they wanted in the first place or the business has changed making it irrelevant.
Here are some very interesting numbers on failing software...
The Standish group released some stats last year stating that "Only 9% of projects in large companies were successful." and that "The most projects, 37.1%, were impaired and subsequently cancelled (Resolution Type 3) in medium companies, compared to 29.5% in large companies and 21.6% in small companies."
With this high rate of failure, how can it possibly be good? Well it is not! Failure is never good, but it is inevitable. What we do however strive for is to mitigate the losses that are incurred due to the failure.
How do we do this?
Fail fast fail often…
Agile methodologies / processes
In contrast to the structured "long running" processed described above, in agile we get working software into the hands of customers, business or clients as soon as possible. They can then interrogate it and communicate where the problems (if any) are and what needs to be done differently or how to fix it. We can then"pivot" to fix the issues, change the focus or scrap unnecessary functionality to continue delivering business value.
The difference here is that if we do "fail", we lose an iteration's worth of work, which should be 2 - 3 weeks. Compare this to the months or years that a structured process could take...
Another difference is that we can then learn from the mistake, make an adjustment and continue delivering value. In structured processes the monolith has been developed and you may very well be too far down the path to make the required changes or fix the issues.
In a nutshell:
Failure is not good, but it is inevitable. Things are changing too rapidly for us to start with a plan and be able to deliver relevant software months/years later.
We need to deliver small chunks of work that can be interrogated and evaluated, gather that feedback and communication and adjust what and how we do things to mitigate the risk and exposure of the failures or losses!
If you recall correctly the Limited access group means that if you are in that group, you do not need a CAL to access TFS Web Access. It also meant that you can only see a very scaled down version of web front end which basically gave you access to the work items that you created.
Things have changed.. Now you have power!
Instead of the previous "Limited Access" group, there is now a Stakeholder group.
The allowed features have gone from "View My Work Items" to :
Where TFS has been hiding in the developer realm within corporates, this move IMHO opens up TFS to adoption in big business, where getting everyone on board from a licensing perspective can be a huge expense.
Don't get me wrong, trend charts and pull requests in TFS 2013.4 CTP 1 are big, but you can have all the charts in the world, if the bar to entry for the stakeholder is too high, it is not going to give you the benefit that you need.
I can't wait until the CTP2 when the Stakeholder licensing is suppose to be finalised!
Last week Microsoft hosted a Release Management for Team Foundation Server 2013 talk where I ran through managing releases using Release Management.
I am pleased to say that there was literarily not a seat available, and the audience was responsive and interested. This is obviously a topic that is on a lot of people's minds.
For more information, you can visit the official site.
If you are interested, I have uploaded the slides here.
We will have to try and schedule a similar event shortly
Thank you to all those that attended and participated, and to Microsoft for making it possible.
Getting to know Release Management…
In partnership with Microsoft SA, Team Foundation Consulting will be bringing you an afternoon focussed on Release Management.
Join us and see how to manage your deployment to create better value.
This event is free and seats are limited.
Please reserve your seat now.
January 23rd 2014 saw the launch of ALM days SA in Cape Town.
This event was organised and sponsored by Team Foundation Consulting, South Africa’s only consultancy focussed solely on ALM, TFS and Visual Studio.
Attendees came to learn about updates to Microsoft’s Application Lifecycle Management offerings which enable software development teams to be more productive and to collaborate more effectively.
The event aimed to provide insight, advice, strategies and techniques to improve quality and ensure that the final application meets the needs and expectations of users
A HUGE thank you to all who attended and participated in the first ALM days!!
We had a lively crowd of about 40 people, all of whom chose to spend their day learning something new.
Some of the positive feedback from those who attended…
“Broad coverage of topics, well done”
“Keynote was excellent, Agile was interesting, looking at new tools & features was great…”
“Great presentations, very informative. Awesome keynote…”
“…Lunch awesome & venue great. Thank you for taking the initiative of organising this day. Much appreciated.”
“Would be nice to see this every year.”
“Nice mix of topics – technical & theoretical.”
“Good speakers, good content, good location, learned a lot.”
“Hope you host TechDays 14.”
Thank you to all our SPEAKERS who helped to make this event possible!
Roderick Lim Banda, our Keynote speaker, set the tone for the day and got everyone thinking about the future of IT and the people who are involved in the industry.
”Awesome keynote…” “Enjoyed Roderick’s views on CPT IT industry.” “Keynote was excellent…”
Cara Turner gave us some insight into a real world business situation where Agile proved invaluable.
Daniel van Wyk showed us how to incorporate SQL in the development process.
Dawie Snyman showed us a few of the cool features in TFS 2013.
Niel Zeeman provided insight on how to incorporate Quality Management & Enablement in day-to-day processes. He also showed us what is possible when it comes to Continuous Deployment as a key concept in Velocity Culture and how it all comes together.
At Team Foundation Consulting, we saw the need to have
an ALM event where developers and members of the IT community could share experiences, learn new concepts, have access to experts and engage with likeminded individuals.
Judging from the feedback from those who attended…we were right!
We are proud to have launched ALM days, and we look forward to making the next one even better!
Team Foundation Consulting will be launching ALM days in Cape Town on 23rd January 2014!
Learn about updates to Microsoft’s Application Lifecycle Management offerings which will enable your software development teams to be more productive and to collaborate more effectively. This event provides insight, advice, strategies and techniques to improve quality and ensure the final application meets the needs and expectations of users.
Reserve your seat today!
Find out more at www.alm-days.co.za
The event is free and seats are limited.
Join us for an awesome day of ALM!
Finally, the time has come for us to launch the first ALM days in South Africa.
Learn about updates to Microsoft’s Application Lifecycle Management offerings which will enable your software development teams to be more productive and to collaborate more effectively.
This event provides insight, advice, strategies and techniques to improve quality and ensure the final application meets the needs and expectations of users.
The event is free and seats are limited.
Date, venue and agenda to be confirmed soon.
Cape Town Event
If you are interested, sign up on www.alm-days.co.za and be first to be notified once all the details have been finalised.
We look forward to you joining us for a day focussed on Application Lifecycle Management.
Learn – Discuss – Question – Engage
Meet new & interesting people…
Let me give you a hint: Not only is it faster, it’s also more reliable! (There, blog post done : )
Let me expand on the above:
Seriously, a lot faster.
Anybody that’s ever had to sit and pay VSS tax while dreaming of your post work beer, waiting for a history lookup, a search, or especially “View difference” would know what I mean.
There is a great difference in architecture between the two. I’ll discuss a few to give you an idea of why you should consider moving.
TFS Uses a SQL database to store Team Project Collections; VSS uses a File System. So how is this better?
· Size – (Yes it does matter) VSS can store up to 4GB reliably; TFS can go into Terabytes
· Reliable – Ever had a network error when checking in on VSS? You’re left with corrupt files and a caffeine overdose. TFS commits a transaction which can be rolled back if there is an error
· Indexing on the tables so faster searches – Did I mention TFS is faster?
· And of course, having a DB as your data store, you can have all the usual goodies like mirrored and clustered DB’s for TFS, so you never have to lose anything or have any down time!
TFS uses HTTP services vs. file shares (That should be enough said)
· Option of a TFS proxy for remote sites to save bandwidth and speed things up a little
· Did I mention that TFS is faster?
TFS uses Windows Role-Based Security vs. VSS security (I don’t think the methodology was good enough for someone to even come up with a name for it – I’ll just call it Stup-Id, there we go, you’re welcome ;)
Windows Role-Based Security vs. VSS’s Stup-Id:
· With Win Roles you can specify who’s allowed to view, check-out, check-in and lots more. With Stup-Id you can set rights per project, but all users must have the same rights for the database folder. This means all users can access and completely muck up the shared folders. Not pretty.
Extra functionality and pure awesomeness:
· Shelve sets – this is really handy to store code if you don’t want to commit it just yet. Say you go for lunch and you’re afraid that BigDog might chew up your hard drive again: all you do is shelve your code – this stores it in TFS. Once you’ve replaced said eaten hard drive you just unshelve and... tada! No need to say the dog ate my homework.
· Code review – Developer A can request a code review from another developer who can add comments to the code and send it back. (Basically sharing a shelve set)
· Gated check-ins: You can set rules to only allow check-ins when certain conditions have been met. For example, only check in code when:
o the code builds successfully, or
o all unit tests have passed, or
o the code has been reviewed
· Work Items – Bug/issue tracking made with love removes that nagging feeling at the back of your mind that one of these days there will be a PHP or MySQL update that breaks your free open source ticketing/bug tracking system.
· Change sets – basically all the items that you’ve changed and are checking in. You can also associate change sets with work items for better issue tracking.
· Build automation – automate build and deploys (How cool is this?)
But for me the Pièce de résistance is:
Have you ever had a new developer change files outside of the IDE? Maybe change the read-only attribute and made some changes? This completely confuses VSS and is a great way to get your source control out of sync. In TFS you can edit files outside of the IDE to hearts content and TFS will pick it up and queue for the next commit.
How to move?
Google “Visual Source Safe Upgrade Tool for Team Foundation Server” and follow the instructions.
And that is why TFS will make you happy. Better source control means better code quality, leading to happy customers, and maybe being the next Bill Gates (unless you wanted to be Guy Fawkes).
So, one of the tenants of ALM is automation, and probably one of the most time consuming and problem prone aspects of the lifecycle is deployment.
It just so happens that I have been in a couple of discussions around how the gap between when the developer “completes” and what is moved into QA, UAT or Prod environments is actually bridged. In fact, I know of a notable company losing a great deal of money due to a critical system being down for a day because one step was not completed by the deployment team.
We all know that continuous integration is a “basic right” when it comes to development environments, and recently there is an emphasis on continuous deployment, but how do we package and move deliverables from one area to another?
So I want to start with packaging.
There are a couple of ways that we can package our applications, based on the technology that they are built in, the target environments and/or the amount of configuration that is needed when deploying.
Remembering that “If You're Using XCopy, You're Doing It Wrong”, these are a couple of techniques / tools I would keep in mind:
Visual Studio used to have a “Microsoft” installer project type that was available with VS 2010 and earlier. It was fairly intuitive, and I know a couple of companies that have not considered upgrading due to an investment in this project type.
InstallShield Limited Edition was also packaged in VS 2010 and is still available with VS 2012, although limited, it does provide basic functionality and some integration with build environments.
There are a couple of other msi creations, but my favourite has to be WiX. It was actually almost a part of Visual Studio, but then it was decided that that would limit the release cadence and inhibit the flexibility of fixing changes and adding new functionality.
It is a highly flexible platform, plugging into builds without much effort.
And if you are wondering if it is any good, a large number of Microsoft’s applications are actually released using a WiX based installations.
You have had the ability to “publish” sites in Visual Studio for a while now, but it was basically a “smart” xcopy. In recent years there has been quite a bit of work done on the Web Deploy or MS Deploy utilities. It is basically an extensible framework with providers that provide certain capabilities.
One of the more significant abilities is to deploy web site “packages” to IIS, then there is the “dbDacFx” provider that will actually deploy database changes to target servers as part of the deployment.
This is indeed a powerful tool for the deployment arsenal, especially when working in load balanced and “highly available” environments.
Integrating this into your build is also a synch, merely add a couple of msbuild parameters and you are a-for-away. More complex publish scenarios may involve you resorting to the “InvokeProcess” activity, but that is not so bad either.
(Indeed, Scott Hanselman’s quote "If You're Using XCopy, You're Doing It Wrong” is a session on web deploy that he did)
If you are working in “client deployable” environments, such as Winforms, or Wpf applications, ClickOnce should definitely be a consideration. It is once again easy to integrate in a build process and if you can get away with merely “copying” assemblies across, then you have a winner.
NuGet is fast becoming the de-facto standard for packaging components in the development environment. Companies have also started adopting it in their release management due to the ease of integration and modification. It is a very simple, yet powerful way of packaging and publishing components. With configuration, and even source code transformations and PowerShell scripts, you can pretty much do anything during install or remove actions.
|Install Time UI|| |