Build scripting with psake

Editor's Notes

• #4: Its release day
• #5: Its release day
• #6: Its release day and the team has gathered for their morning standup. The tech lead Mark turns to the recently hired Sarah and says "Its tradition to have the newbie do the release so that they get familiar with the process. Theres a README included in the solution and it has all the steps. Let me know when you're done so I can let the business know." Now Sarah has been around the block a few times and has had no problems deploying software in the past so she says what the heck I'll give it a shot.
• #7: So she opens the readme and finds something that closely resembles this: She needs to move files from one folder to another, Run the linter, Deploy stored procedures to the sql server, run tests and use the little orphan annie decoder pin to decipher the rest of the steps. It all looks a bit challenging, but being the new member to the team she doesn't want to give up too soon. So....
• #9: The release has yet to go out, support is starting to get calls because for some reason the website now just points to a picture of Steves Cat.
• #12: Automation Rarely is your application so simple that the default build button does everything you need it to do You may have any number of tasks that may need to happen in any given order to fully build and run your application For example on the project I am currently on, we must deploy stored procedures and functions, move files around and run entity framework migrations We want these tasks to be done consistently before builds, psake allows us to automate this As these tasks grow in numbers and complexity us humans get worse and worse at remembering all the tasks need to run before we can ship our code Lets let our computers do what they’re best at which is following a set of instructions
• #13: Config as Code Your build steps are captured as code instead of a readme The build script is always checked in with your code and therefore kept up to date If you ever need to revert changes to a prior commit, your build will still work Eliminates the “works on my machine” adage Every developer should be able to run the build and have it work the same On our project we had developers saving cmd shortcuts to their desktops to run pre build scripts, now we use psake and every developer has access to the scripts this gives us is consistent and repeatable builds. The build will work the same on every machine every time
• #14: Simplify your Deploy With a build script you can take your deploy step down to a single command line command. Releases become non events No more huddling around orchestrating the deployment with your team, simply execute your deploy command deploy independently from CI like Jenkins and TFS. You can take your multi step build process down to a single one. As mentioned in the slide before, if you need to revert back to a previous revision, that may require changing your whole build process, With a build script, your build and deployment processes are always in line and up to date with your code
• #15: XML should be used to describe things not script things Rake requires you to write Ruby code which can be foreign to dotnet developers Rake also forces you to install Ruby gems which your standard windows box will not have
• #16: A lot of .NET developers may already have experience with powershell
• #17: psake is a domain specific language to create builds using a dependency pattern just like Ant, NAnt, Rake or MSBuild. Tasks are the core of Psake, They are what you break your build steps down to Recommend you handle your script like you would your code, with modularity You can make these tasks depend on each other You can pass parameters to theses tasks These tasks can make use of properties And because it is written in powershell you can write your own functions
• #18: Show the project, simple fizz buzz tdd with some fake acceptance tests Demo building, cleaning, testing Show dependencies
• #22: Environment to deploy to
• #24: Run only if params not null or empty
• #25: psake Deploy psake Deploy -parameters "@{'env'='dev'}"
• #29: Lists the available tasks, their aliases and what the depend on