Jim Bennett
Xamarin MVP Microsoft MVP

Mobile developer at EROAD, Xamarin MVP and Certified Developer, Microsoft MVP, author of Xamarin In Action, blogger, speaker, father and lover of beer, whisky and Thai food. Opinions are my own.

  Auckland, New Zealand
Xamarin In Action
  Xamarin In Action
  Twitter
  GitHub
  LinkedIn
  YouTube
  Email
  CV

Today I've finally moved to the world of continuous deployment - albeit for one of my projects only so far, but it's a start. For my JimLib open source API I've automated the whole deployment process so after checkin it builds and deploys to NuGet automatically.

Steps in the process

I do all my development in Visual Studio, which now can connect to git. I have this wired up to my GitHub repo so I can commit changes to my local repo and sync back to GitHub.

Once changes are synced, I use AppVeyor to do my builds. They provide a free service for public repositories so can automate all open source builds without you spending a penny. I have set this up to:

  • Pick up pushes to my repo
  • Increment a version number and set this in AssemblyInfo.cs
  • Build everything
  • Run all unit tests
  • Package up the NuGet package including symbols
  • Push the NuGet packages to NuGet.org

AppVeyor even provides markdown for a build status:

Build status

How can I be sure I'm deploying the right thing?

This is where unit tests come in. I try to get as much coverage as possible (91% at the moment), and use this to provide a level of certainty that any new changes work (assuming my tests are good) and that I haven't broken anything with any new changes. The build process runs the tests and won't push the package unless all tests pass.

Downsides to AppVeyor

AppVeyor is very good, I'm really impressed with what they offer for free. It's not fast to get a build, sometimes you can be waiting for up to an hour but for free thsi is fine. The only downside so far is NuGet package restore. They always provide a clean environment to build on and even with package restore turned on you have to build twice with they don't do. It means you have to check your packages into git. Not the end of the world, but a bit annoying.




About the Author

Jim Bennett

International C# and Xamarin geek - Microsoft MVP, Xamarin MVP and Certified Developer, blogger, speaker, father and lover of beer, whisky and Thai food

 

Today I've finally moved to the world of continuous deployment - albeit for one of my projects only so far, but it's a start. For my JimLib open source API I've automated the whole deployment process so after checkin it builds and deploys to NuGet automatically.

Steps in the process

I do all my development in Visual Studio, which now can connect to git. I have this wired up to my GitHub repo so I can commit changes to my local repo and sync back to GitHub.

Once changes are synced, I use AppVeyor to do my builds. They provide a free service for public repositories so can automate all open source builds without you spending a penny. I have set this up to:

  • Pick up pushes to my repo
  • Increment a version number and set this in AssemblyInfo.cs
  • Build everything
  • Run all unit tests
  • Package up the NuGet package including symbols
  • Push the NuGet packages to NuGet.org

AppVeyor even provides markdown for a build status:

Build status

How can I be sure I'm deploying the right thing?

This is where unit tests come in. I try to get as much coverage as possible (91% at the moment), and use this to provide a level of certainty that any new changes work (assuming my tests are good) and that I haven't broken anything with any new changes. The build process runs the tests and won't push the package unless all tests pass.

Downsides to AppVeyor

AppVeyor is very good, I'm really impressed with what they offer for free. It's not fast to get a build, sometimes you can be waiting for up to an hour but for free thsi is fine. The only downside so far is NuGet package restore. They always provide a clean environment to build on and even with package restore turned on you have to build twice with they don't do. It means you have to check your packages into git. Not the end of the world, but a bit annoying.