VSTS - Scheduled release, Azure and XCode build

One more month, one more exciting release of Visual Studio Team Services.

These are my top 3 new features of this month:

Multiple schedules in releases

Want to schedule your releases to be created more than one time in a day? You can now configure multiple scheduled triggers in a release definition.

Simplified Azure endpoint creation

In an earlier sprint, VSTS team made it easier to create a new Azure Resource Manager service endpoint from Team Services. That experience only worked in accounts that are backed by an Azure Active Directory. In this deployment, they are bringing the same simplified experience for all the other accounts that are not backed by an AAD. So, if you are a MSA user and have an Azure subscription that you would like to deploy to from Team Services, you can create an Azure endpoint without having to run tedious Powershell scripts or following a blog.

Xcode 8 signing and exporting packages in the Xcode Build Task

The Xcode build task now supports building your projects using Xcode 8 automatic signing. You can install the certificates and provisioning profiles on the build server manually, or have the task install them by specifying the File Contents options.

Xcode 8 requires specifying an export options plist when exporting an app package (IPA) from an archive (.xcarchive). The Xcode task now automatically identifies the export method if you are using Xcode 8 or Xcode 7. You can specify the export method or specify a custom plist file from the Xcode task. If you are using an Xcode version older than Xcode 7, the task falls back to using the old tool (xcrun) for creating the app package.

VSTS - Manual deploy, Git imports and Queues

Here we are for a new episode of my personal "top 3 new VSTS features" series. Let's talk about September.

Deployment manual intervention

You can now pause execution during deployment to an environment. Including a Manual Intervention task enables you to pause a deployment, perform manual steps, and then resume further automated steps. You can also reject the deployment and prevent further steps from executing after a manual intervention.

You should note that a manual intervention task splits the overall execution into three phases. 

• The first phase runs on an agent, and after it is done, the agent is released. 
• The manual intervention phase does not require any agent. 
• After it is completed, any tasks following the manual intervention task are run in the third phase, possibly on a different agent. The artifacts are downloaded during both the agent phases, since different agents may be used for both of them. You should not assume that the state from the first phase is available during subsequent phases.

Import Git repositories

We can now import a Git repository from GitHub, BitBucket, GitLab, or other locations, into Visual Studio Team Services. You can import into either a new or an existing empty repository.

To import into a new repository, from the repository selector drop-down, click Import repository. 

If the source repository is a publicly available repository, then simply provide the clone URL of the source repository and you are good to go.

However, if the source repository is a private repository and can be accessed using basic authentication (username-password, personal access token, etc.), then check the “Requires authorization” check-box to provide the corresponding credentials.

Instead, to import into an existing empty repository, on the Files page, click the Import repository button and provide the clone URL. You will need to provide credentials if the source repository is private and requires authentication.

Build queue tab

They've implemented a new design for the Queued builds page that shows a longer list of queued and running builds, and in a more intuitive fashion. Looks good...

About Xamarin build (again)

Back in April, in one of my posts (read it here) I explained  that it was no more necessary to  include the "Xamarin License step" when building Xamarin solutions using the Hosted Agents.

Starting from now, it is no more necessary to include this step for every Xamarin builds, for both Hosted and personal agents.

Indeed, as reported on the new Visual Studio Team Service update: 

The Xamarin License step is no longer necessary and has been removed from the build templates shipped with VSTS and TFS 15. As part of this effort we will also deprecate the task. All build definitions that use this task should be updated to remove it in order to prevent any disruption when the task is finally removed.

Have good builds ;)

VSTS - Files, Details and Folders

In august there's been only one update to Visual Studio Team Services. Let's take a look at my 3 favourite new features for this month.

Pull requests Files

The biggest new feature in this release is the ability to see past updates made to a pull request. A few sprints ago (July 7th), they released the ability to properly track comments as a pull request is updated with changes. However, it’s not always easy to see what’s between updates. In the Files view, you can now see exactly what changed each time new code is pushed to your pull request. This is really useful if you’ve given feedback on some code and want to see exactly how it changed isolated from all of the other changes in the review.

Improved build details

When you click down to focus on a specific build, it now gives you a lot more information about what's happening and overall code quality. 

Build Definition folders

Does your team have a lot of build defintions? You can now use folders to keep them organized in the All Definitions tab.

Tip: Have a batch of definitions that need the same permissions? Put them in a folder and then you can give permissions to the folder

VSTS - Azure, Comments & Redeploy

Here we go with my 3 favourite new VSTS features for July.

Release management - Azure deployments

Now, setting up an Azure Service endpoint is easy: you just need to select the subscription on which to create a service endpoint, and you are ready to deploy to Azure.

• Users can now automatically set up an ARM service connection by selecting the subscriptions linked with the Azure Active Directory that is backing the VSTS account.
• Note: A new Azure Service Principal will be created and assigned the Contributor role, having access to all the resources in the selected subscription. You can modify the Service Principal access from Azure portal > Subscriptions > Users > Roles.
• Prerequisites: -The VSTS account should be backed by an Azure Active Directory. For more info, see the Visual Studio article Team Services: Access with Azure Active Directory (Azure AD).
• Note: Only Azure subscriptions that are linked with the Active Directory are listed.

Comment tracking for pull requests

Pull requests in VSTS have been improved to show comments left in files on the proper line, even if those files have been changed since the comments were added. Previously, comments were always shown on the line of the file where they were originally added, even if the file contents changed—in other words, a comment on line 10 would always be shown on line 10. With the latest improvements, the comments follow the code to show what the user expects—if a comment was added on line 10, and two new lines were subsequently added to the beginning of the file, the comment will be shown on line 12.

Here's an example change with a comment on line 13.

Even after the code has changed to shift the line with the original comment from 13 to 14, the comment is appearing in the expected place (line 14).

I think this improvement is a big step forward for improving the code commenting experience in pull requests. In the near future we will have even more improvements coming, including improved comment placement for renamed or moved files.

Release – redeploy after success

When a deployment to an environment fails, you may want to be able to redeploy an older release that already succeeded once in that environment. This feature lets you do just that. 

When you try to redeploy an older release, you will be shown the list of commits as well as the list of work items that will be rolled back. You just need to make sure that the automation scripts for deployment can really handle the rollback scenario. That is still on you.