Over the past few months we’ve been working hard to keep up with a growth of new users starting out using OnCheckin for their project’s deployment. We haven’t just been sitting idly by though. We’ve been steadily adding to the list of functionality that OnCheckin offers, so we thought we’d take 5 minutes to walk through it with you in a little more detail.

Multiple Deployment Environments (Development, Staging, Production)

The biggest addition we’ve added to our service is the support for multiple deployment environments. This allows you to promote your successful releases between up to 3 different environments, for example development, staging and production. Depending on your feedback we may grow this number in the future.

This change brings a new deployment configuration tab for managing your project, as well as support for adding new environments when your application is ready to scale to a different deployment model.

You can name these environments anything you like and this will be displayed elsewhere in the dashboard for your project.

Then once you have more than one environment OnCheckin treats your project as a deployment workflow instead of just a single environment project, and this is then also visible from the deployment manager when looking at your projects:

By default when your project is enabled for auto-deployment only the first environment in your workflow will deploy to. We assume that this your development or test environment.

After deployment to your first environment is complete you simply need to view the results for your project and use the new “Promote” icon next to a successful past deployment.

Unsuccessful deployments cannot be promoted.

When you click to promote a successful release this dialog will launch:

Environment based web.config transforms

With the addition of support for a separation of your server environments we’ve also added support for a new web.config transform model that allows up to 3 different web.config transforms to be layered on top of each other as part of any given deployment.

For example this allows you to apply transforms in the following order;

• web.release.config (we always build in release mode).
• web.oncheckin.config (this runs on every OnCheckin build).
• web.[Your environment here].config

You can read more about this here.

We’ve even written a Visual Studio Extension to make it easy for you to create your own environment web.config transforms.

Project renaming

Another requested feature was for the ability to name your deployment projects as you liked.

Until this last release your project was named after the web application project name in your solution. This meant that if you named your projects after their namespaces you would end up with a project name like “MySolution.ProjectName” or if you had multiple copies of the same project deploying to different environments (maybe you deploy the same CMS to many different clients?) you had no way of differentiating between your deployment projects.

Well now you can rename your deployment projects as you see fit.

Simply open your project up by selecting it in the deployment console.

Once you’re in the project configuration editor, simply hover over the name of your project at the top of the page and click on it to begin editing.

Once you’ve edited your project name, simply review and save your project.

Your new project name will then be reflected throughout the site, your reports and emails.

Support for Git Branching

Another commonly requested feature was being able to deploy from a specific Git branch.

OnCheckin has always supported using SVN and TFS branches as deployment sources, but this was based purely on the fact that these source control providers use Urls to map their branches.

Our Git source control support now supports using a branch as a first-class build and deployment source – all you need to do is define the branch in your project’s source control setup.

Remember that this cannot be changed between environments, so if you set this to a certain branch all of your environments will deploy from this branch. You cannot have different branches in use between deployment environments in the same project.

This is by design – we believe that the code you and your team release to your development and staging environments should be the same code that you put in production. If you wish to deploy different branches to different environments, we suggest you use two separate OnCheckin deployment projects instead of using a deployment workflow.

We want to hear your feedback!

We’re constantly working to make deploying your ASP.Net websites as fast, easy and reliable as possible.

But above and beyond our roadmap, we value your feedback above all. So if you want us to fit your ideas into our next release we welcome you to get in touch by email or twitter or add and vote for your change on our trello board.