Der agile Festpreis mit Scrum und Prince2

In der Softwareentwicklung sind ein agiles Vorgehen und agile Schätzmethoden bereits Standard. Bei klassischen Ausschreibungen und in Lieferanten-Kunden-Umfeldern ist dies leider nicht der Fall. Hier wird nach wie vor versucht, das Risiko durch eine möglichst detaillierte Beschreibung der Endlösung zu minimieren. Leider funktioniert die detaillierte Planung vor Projektstart nicht, da der Fachbereich die Zielplattform und technischen Möglichkeiten und der Lieferant die Fachdomäne nicht kennt. Das Ganze führt dazu, dass im Projekt Lieferant und Kunde mehr gegeneinander statt miteinander arbeiten und meistens direkt nach Start des Projektes die Verhandlung von „Changes“ beginnt. Über den agilen Festpreis und den Scrum-Reifegrad hatte ich … Continue reading Der agile Festpreis mit Scrum und Prince2

ALM Days 2016 in Köln

In einem Monat ist es soweit: die ALM Days finden dieses Jahr in Köln am 13. und 14. April statt. Wie jedes  Jahr geht es hier rund um die Themen Application Lifecycle Management, agile Entwicklung und natürlich DevOps. Als Speaker sind wieder viele Experten von Microsoft aus Deutschland und den USA und viele meiner MVP Kollegen. Die Anmeldung ist noch offen. Wer sich also bisher noch nicht angemeldet hat, kann das jetzt noch tun. Jetzt anmelden Die ALM Days sind für mich eine der besten Veranstaltungen im Jahr. Man kann sehr gut kontakte Pflegen und bekommt wirklich immer das aktuellste … Continue reading ALM Days 2016 in Köln

How to move build definitions in TFS to other projects using the REST API

The new build system in TFS or VSTS supports saving build definitions as templates. The problem is, that this only works inside a single TFS project. If you want to share your definition with other projects you have to use the REST API. First you have to extract your current build definition. Get a list of all build definitions and check the ids. Then use this ID to get the full definition. Now save the json to a file and remove all the clutter like _links, revision etc. I’ve marked all the sections that you can remove in the following … Continue reading How to move build definitions in TFS to other projects using the REST API

Missing files in MSDeploy package

Problem If you create an MSDeploy package for a SharePoint or O365 AddIn (a.k.a App) in a team build the package does not include all files (like i.e. language resources). Reason This seems to be a bug in MSDeploy. If you build the app only with /p:Ispackaging=True everything works fine. You get a web package inside the app.publish folder that contains all files. If you work with multiple Publishing Profiles and specify an explicit profile strange things happen. /p:DeployOnBuild=true /p:PublishProfile=NameOfPackageProfile You still get the package but if you look inside the package the folders are missing. Solution If you can … Continue reading Missing files in MSDeploy package

Release management trial license has expired

The license of the Release Management Server at one of my client expired multiple times. This time I was really sure that I had installed the correct version from MSDN. When I looked around I found the answer on msdn. As it turned out the problem is not, that the license had expired. The user under which the application pool is running has to load a user profile to read the license. This can be configured in iis. Continue reading Release management trial license has expired

Bugs not on the backlog after Update

If you Update yout TFS on premise from 2013 to 2015 or from 2015 to 2015 Update 1 you might experience that your bugs are no longer displayed in your backlog. This is can now be configured for individual teams. Open the settings for your project. Click on the team that you want to configure. Got to settings and configure how the bugs are handled in the backlog of the team. The bugs then appear again on your backlog. What you shouldn’t do is modify the workitem categories like some posts suggest. If you do this you will lose the capability … Continue reading Bugs not on the backlog after Update

Run Pester tests in PowerShell ISE with IsePester

Today I stumbled upon a package in chocolatey that I wasn’t aware of. It’s called IsePester from @dfinke. If you develop you PowerShell scripts with ISE and run Pester tests this is a really nice package. If you haven’t played around with chocolatey – do it. It’s a really need packaging manger that makes setting up your dev machines really easy. To install chocolatey just run the following command in PowerShell: To use Pester you have to install it. If it is already installed you can override it with -–force / -f Install IsePester the same way… If you now … Continue reading Run Pester tests in PowerShell ISE with IsePester

Use Pester to author your PowerShell scripts

Pester is a great module for testing your PowerShell scripts and modules. It has great mocking support, a test drive for setting up isolated files and supports a lot of assertions. Since the importance of PowerShell growths, testing your scripts is a must.

This is part 2 of the series “Develop next level PowerShell with Visual Studio and Pester”. It assumes that you have a Visual Studio solution with a basic Pester Test in GitHub.

Post Content
Part 1: Develop next level PowerShell with Visual Studio and Pester In this post I focus on creating the project in Visual Studio and interacting with a source control system like git.
Part 2: Use Pester to author your PowerShell scripts using TDD/BDD This post focuses on writing PowerShell scripts or modules using Pester as a TDD/BDD framework.
Part 3: Run your Pester tests in a VSTS build In this post I show you how you can run you tests in a continuous integration build and display the build status with a badge in your repository.

 

Pester basics

If you create a new test in Visual Studio, it looks like this:

Describe "PowerShellTest1" {
    Context "Exists" {
        It "Runs" {
        }
    }
}

As you can see you have three levels:

Describe: This is the name of the test displayed in test explorer. It is not ONE test in the test results. It’s more a container scope for many tests that executes as a unit.

Context: Like “Describe” the Context is a container for tests. You can mock functions or have test files in the scope of a context.

It: “It” is the actual test. You add an assertion here to test the state of your system. “It” is also a scope for mocking like context.

You can use these elements to structure your tests in a BDD style after the GivenWhenThen pattern.

$project = (Split-Path -Parent $MyInvocation.MyCommand.Path).Replace(".Tests", "")
$sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".tests.", ".")
. "$project\$sut"

Describe "AnswerToUltimateQuestion" {
    Context "Given an enormous supercomputer named Deep Thought, when we ask the ultimate question about life, the universe, and everything" {
        It "should return 42" {
			       AnswerToUltimateQuestion | Should Be 42
		     }
    }
}

Continue reading “Use Pester to author your PowerShell scripts”