It’s rather easy to create a basic package, but step beyond the basics and the story isn’t laid out clearly before you.  Many jump on the Config Transform wagon, building 9 versions of their app for each environment they may target.  Transforms look good at first, but then you’re compiling your app 20 times and it just get’s annoying.  I’d much rather build once and specify the parameter transformations at deploy time.  That’s what I’ve got for you today.

Here I’ll walk you through creating custom parameters for deploy time change via MSDeploy.

I’m using an ASP.Net MVC 4 Internet Project, but it’s not critical.

Environment Specific Settings

To emulate an environment specific setting, I’ve added appsetting EnvironmentImIn.  I’ll commit this with the Get Latest and Go™ value of LocalDev. 

Building the Package (Manually)

Right click the project MVC project and click Build Deployment Package. 

This will create your package as a folder with a series of files under <Project>\obj\package.

Great, but we don’t deploy from dev machines ‘cause we have a habit of installing crazy stuff.  You should…

Build the Package (Automation)

ASP.Net project files, being MSBuild files, have a target called Package.  This will first compile the project and then generate the package folder just like VS did above (Details).  You can adapt this with ease to TFS, TeamCity, etc.

Deployment Parameters

MSDeploy uses a parameters.xml file to determine what is “changeable” at deploy time.  This file is consumed at package creation time.  I consider this a good thing since you end up committing the file and are explicit about what’s changeable. 

If you look in the .zip file in your package directory you’ll find a default parameters.xml.  This is because VS/MSBuild makes certain things changeable by default.  If you drop a parameters.xml file into your project root, MSBuild will use that.  Coolio.  Here’s ours:

Vishal Joshi does all the hard work of explaining what the elements all mean here.  Vishal is the man!  What we’re doing is adding a parameter EnvironmentImIn, giving it a description, and then telling MSDeploy how to find the entry.  Beware, there be regex in them thar hills.

Changeable Package Settings

If you build your Deployment Package now (msbuild /t:Package) you’ll find the *.SetParameters.xml file now contains our EnvironmentImIn setting where before it only had IIS Web Application Name and DefaultConnection.  Saweeet!

The *.zip file will also have a parameters.xml file like this:

Deployment (IIS Manager)

I find many deployment teams like to do their magic manually.  These are often the infrastructure or a Release management group.  They spurn the console at their own peril.  IIS is cool with that though. 

You can import packages through IIS Manager and you’ll be presented a UI to change your setting.  #huzzuh!

Set it to “Staging” and Finish click Finish results in:

Deployment (Command line)

One of the convenient pieces created for you by msbuild /t:Package is the MSDeploySample.deploy.cmd file.  It helps parse parameters and construct the not so straight forward msdeploy.exe command line.

If you don’t want to mess with msdeploy.exe directly, you can customize the SetParameters.xml file and just run the cmd file like this:

MSDeploySample.deploy.cmd [/T|/Y]

/T means tell me what’s gonna happen, but don’ t actually do anything yet.

/Y is for the big kids.  Applies the changes.

The alternative is to supply –setParam like this

–setParam:EnvironmentImIn=Staging

Easiest way to construct an MSDeploy.exe command line is to use the .cmd and modify what it gives you.  Look here for detailed –setParam options.

That’s crazy talk that leads straight to the ivory-tower.

We just need to expose people to the alternatives as often as we can.  Expand their normal. 

So here I want talk about evolving towards a more change friend solution using the scenario of calculating bonuses that is similar to what was being discussed in the forum.

Warning: the code below was not run.  While it’s meant to be javascript, it’s not meant for copy, paste, execute.

The YAGNI Solution

This is certainly readable and understandable.  It’s also crazy simple and likely to get more complicated.  When that happens, how do we transform the problem?  How do we use the alternatives so that when one part of the problem changes, the entire solution does not in churn?

The Less Cohesive Solution

We’ve moved the calculation into it’s own area.  That’s pretty nice.  But it seems likely that when criteria change, so will the calculations.  When one thing churns so will all others.  We’ve spread around what it means to get a “Great” review.

A More Balanced Solution

What would be nice is if adding, changing or removing any single bonus category was self contained.

At this point, what we find as the point of churn (each business decision) is now isolated.  The contract between the entry point of calculating the bonus and the actual calculators is in the registerCalculator implementation.  We’re assuming that won’t change much.

More Code != Better

This is not a hammer for all of your business decision nails.  It is certainly more complex.  But we must balance complexity, cohesiveness, and correctness with all the other things we value.

The first solution is not “bad”.  I would ship that first solution.  I’d adjust my system over time so that change was enabled in my architecture.

ZOINKS!

We’re seeing the two commits that differentiate the upstream branch defunkt/master and plastictrophy/master.

You won’t find any link or button to get this view… it’s Double Super Secret.  Instead just construct the url as follows:

http://github.com/<handle>/<repo/compare/<branch>

If the handle/repo is a fork and the branch is owned by upstream, you’ll get what we see above.

It appears to work on simple branches too:

For the purposes of this I’m using https://github.com/defunkt/resque.

 

> git clone git://github.com/defunkt/resque.git

> git remote add plastic git://github.com/plastictrophy/resque.git

> git fetch plastic

> git diff origin/master plastic/master

Comparing branches the same way, just remove the repository reference.  For instance,

git diff master myfeature

One thing that was killing my workflow was leaving PowerShell to share some snippet of code or a file as a Gist.  In Visual Studio we have Gister, but when I’m in PS I hate having to break my cycle. 

Well no longer… 

Introducing PsGist

PsGist provides a PowerShell function called (wait for it) gist.  Try not to forget that one, ok?  The usage is simple:

gist [[-File] <FileInfo>] [[-Description] <String>] [[-Username] <String>]

Username is optional.  If you don’t provide it your gist will be public and anonymous.  If you do, you’ll be prompted for your password.  This is different than Gister where I only prompt once and cache the creds.  Here you’ll have to specify the password each time.  Deal with it or fix it.

Here’s an example: 

Notice how after the gist is created the Url is written to the console/host?  Well PsGist also puts the Url into your clipboard.  So you can quickly go to IRC, IM, Twitter, etc and past the Url.  Or you can use ALT+<Space>, E, P to paste it quickly into your console and open the gist.

Needed: Pipe the output

I’d like to be able to pipe the output to start, clip, out-file and other useful commands.  For whatever reason powershell won’t wait on the gist being created before running the following command.  If you know how to make this happen, hit me up on Twitter, send a pull request or leave it in the comments.

Needed: Multiple File Gists

I’d like to be able to run ls | gist and have all the files in the listing sent to a single gist, but there is a problem with convertfrom-json that I’m struggling with.  I have a branch called pipelinesupport that you can try, but it takes single file gists away until I put that back and fix the json issue.

Needed: Make it a Module

This should really be a module.  I’m sure with another hour’s worth of research and effort I could make that happen, but, well, it works.  If you like PsGist and want to make it a Module, I’ll gladly accept the pull request.

Thanks to @Jaykul

For providing the convertfrom-json function used to handle the Github Api response.  PowerShell 3 seems to have this support built in, but that’s not here quite yet.

To clarify we are living here:

For full UI/user tests I’d deploy the whole app, but I still want my Functional Integration tests to be faster and run locally with ease if I can.  For Web API, I was hoping for self hosting.  WCF can do this, but WCF is a giant pile of mud that I’m not interested in attacking.  So I went looking for Web API Self Hosting for Dummies.  Found it.

And here’s how you use it:

Note: I’ve set the folder = “” in this sample since my ApiController is side-by-side with my test fixture.  Assuming your ApiController is in a different assembly than your tests, you can sepcify the namespace: parameter in the MapHttpRoute like this:

namespaces: new[] { typeof(ThingsController).Namespace }

They can be very simple, allowing for much discussion and interpretation (or just interpretation… tisk tisk):

or they can provide a pretty direct message:

Less is More…

During a course discussion with fellow PSD trainers a few years ago I made the statement that I don’t like trend lines.  They remove the discussion, the thought from this tool.  I preferred NOT to have any forecasts provided by a burndown, because even when aggregated from many teams I can easily make these judgments on my own.  In fact, I believe that, because the decision is not made fore me I actually come out understanding the nuances far better.

The Cut Line

I do think there is a compromise though and it provides a much better basis for the discussion we should be having: what are the possible scenarios ahead. 

Instead of a single trend line, provide at least 2, 3 if you must:

Pessimistic – What is may occur if things don’t continue to go our way.

Optimistic – What is may occur if luck is on our side.

Cutline – What we project might happen if things remain the same.  (What’s the saying?)

Better Discussions

This allows us to have the pointed conversation with our marketing, sales and business teams that we should not be promising, planning or basing important decisions on features that are close to the cut line for a particular sprint or feature.  We probably can begin creating collateral and sales pitches for those features that are near the pessimistic line.  We may also move some of the features near the cutline up if they will win us a customer or two. 

The key is look at the range of scenarios possible and make informed decisions.

All in all, I still don’t think we need the cutline projected, but I do believe that the coloring choices are important.  Some may wish to color the cutline green.  This is dangerous.  It’s not your go line.  The pessimistic line is the most risk averse forecast seen here.

Work expands so as to fill the time available for its completion. ~ Parkinson’s Law, Cyril Northcote Parkinson

On Risk Reduction

Teams talk some good game when they sell Agile to their organizational leaders: real software in a few weeks, higher quality, and, if they’re really good, risk reduction.  “See, if we build these features early,” they say, “and people don’t like it, we’ve saved you 13 months of wasted effort and costs.  How can you not love this stuff?”  Sign me up Johnny!

It’s true, if you build done software in 30 days or less, you do get the opportunity to inspect the output determining whether to stay the course or correct.  You can even begin taking on more creative, innovative, industry shaking adventures knowing they are limited to a few weeks or months.

Looking to become strategic and not just tactical with technology… this is your ticket.

But it’s not all roses. You must expect that some adventures will not end with a pot of real gold. Instead, our gold is measured in learning; new information which can be taken back and used to concoct the next ground shaking advance.  If you allow the fear of failure to drive your decisions you will grind to a halt.  Instead, create a system based on learning and encourage the free communication of that information as a value neutral asset.

On Focus

Tell me you didn’t see this coming.

Every team feels the pressure of a time box.  It’s natural and it can be used wisely.  It can also be abused.  Terribly, terribly abused.  I have good news though!  Corporate evolution is on the side of the wise.

Those who follow the Pomodoro Technique create short, focused 30 minute durations to accomplish activities.  25 minutes exist for actually working the task at hand and 5 are meant to provide the necessary, human break needed to maintain focus over extended periods.

Our Sprints must consciously reflect this same human capacity for focus in a creative environment like software development.  As outlined in our previous part of this series we can easily turn a space for focus and creativity into a pressure box of panic, frustration, and corner cutting.

Sausage stuffing is the two steps back to your previous step forward.

On Decision Making

To support a team in delivering functioning, ship-quality software in 30 days or less, organizations must provide them with timely, informed decisions to questions and alternatives.  Authoritative and informed decisions which take into account the political and user environment are necessary within minutes and hours, not days or weeks.

Would you ever consider the impact of removing 10% of an existing project’s schedule?  In delaying a decision for steering committee or general approval by 1 day, a two week iteration is similarly delayed.  In the absence of responsive decision making and an open social environment for voicing questions and concerns, teams will make decisions and assumptions on their own.

In many of these cases, we may have the best people on the team to make those decisions!  Time boxes demand that our teams be composed of or have direct access to those skills necessary to make decisions quickly.  This includes domain experts such as lawyers, accountants, marketing, design, etc.  With “done” software in 30 days we cannot hide the impact of delayed decisions.

To help me keep track of them and to help others I’m going to catalog them here.

• Methods no more than 3 lines
• No mouse
• No moving cursor more than 2 lines with the arrow keys
• Test Method names at least 40
• All methods/properties names at least 30 characters
• No Classes
• No Mutable State
• No Exposed State
• 3 Refactorings after each passing test
• No If, Else, Switch Statements
• TDD as if you mean it
• No Frameworks
• No IDE

* Replace any number with your preference

If you have ideas for others, put them in the comments and I’ll update the list.

TL;DR

I have an insatiable thirst for new information.  It can be quite frustrating and, at times, debilitating.  The neat thing about new information, is it changes what you consider normal.  Common sense is a bunch of crap.  Using a fork is common sense… until you move to India.  We should all move to India (or vice versa) for a while.

Not to long ago someone described an art course in which many of the lessons included drawing 50 different types of circles or straight lines.  I imagine around 10 or 20 you start struggling a wee bit.  I was reminded of this while reading Zach Holman’s Slide Design for Developers.  He writes:

I took one design class in college. One of the most fascinating assignments they gave us was a study of shape: you get one letter, in one typeface… do something with it. The idea was that the severe limitation forced you to be creative with duplication, rotation, scale, alignment, and whitespace.

Katas give us a silly background story like Triangle Classification, Roman Numerals, or Harry Potter, but those aren’t the point.  The point is not making the next test pass.  In fact, don’t write any tests next time.  They’re getting in your way.  Pick some other area that you feel comfortable in and come up with a constraint outside your Normal so that when you’re done you’ve moved normal a little bit.