Migrating from RM 2013 to TFS 2015 at Payoneer


  Payoneer2    

The migrator tool from RM Server to the new TFS RM is fantastic and can really smooth up the upgrade experience.” – Shmulik Ahituv, DevOps Team Leader, Payoneer

 

 
payoneer.com
North-America
Industry cross-border payments



Profile

Payoneer enables millions of businesses and professionals from more than 200 countries, to grow globally by facilitating seamless, cross-border payments.

 

Situation
Payoneer had 160 release templates for different components in RM2013 and did not want to maintain a release script for each component.

 

Solution

Using the Migrate assets from RM server to Visual Studio Team Services tool created one common release script, to function as a generic template.

 

Software and Services

– RM 2013.4
– TFS 2015.2

 

Ranger Solutions
Migration of release management assets from RM server to VSTS

Benefits

Use one common release script, accessible from all servers, that functions as a generic template, enabling execution of steps with a flag/switch.

 

For more information

You can find the Migrate assets from RM server to Visual Studio Team Services tool in github.com/ALM-Rangers/Migrate-assets-from-RM-server-to-VSTS.

   

Situation

Payoneer had 160 on-agent-based release templates for different components in RM2013 and did not want to maintain a release script for each component.

Solution

Payoneer used the migrator tool to pull a couple of release templates that were comprehensive enough to include all their types of deployment sequences. They created one common release script that functions as a generic template, accessible from all servers via the UNC path. Each function/step can be run with a flag or switch with default values.

The following folder structure is being used

  • DeployerTools – all the RM2013 deployer tools (IISConfig.exe, Irxcopy.exe etc.)
  • HelperFiles – files needed for the deployment for example: new relic config file template.
  • Helper Scripts – custom scripts where each scripts perform an atomic task – equivalent to activities in 2013 or tasks in the new RM.
  • InitScripts – references to the “HelperFiles”, “HelperScripts” and “DeployerTools” folders.
  • ReleaseScripts – common release script that functions as a generic template, using flags to run functions/steps. Each function invokes a script from the “Helper script” folder.

Scripts are stored in a Git repository, using TFS Build for continuous integration (with pester as a testing framework) and RM for deploying them to their shared location described above. The new environment has one release script that invokes other small scripts. Each script and deployment tool does one atomic task, controlled with flags and environment variables. Payoneer splits environments or uses the sequential approvals feature for manual interventions.

Two demo screenshots giving you a sense of what is happening during the deployment and how evidence is logged (click in images to enlarge):

Payoneer_1

Payoneer_2


Challenges

Challenges, such as these, are recorded as issues and resolved in future updates of the migrator tool, or documented as workarounds. Payoneer encountered the following challenges during their migration:

  • PS Write-host command should be replaced with write-output or make a recommendation for custom scripts RM2013.
  • Manual intervention inside of a rollback script caused an error in the migrator. They had to delete the man intervention.
  • They had to use invoke-expression instead of the “&” character, to execute a script from the script within the new RM “PowerShell on remote” task.

See github.com/ALM-Rangers/Migrate-assets-from-RM-server-to-VSTS/issues for more information on these issues,

  • #14 Replace Write-Host with Write-Output in generated scripts
  • #15 Manual intervention in rollback block causes error
  • #16 PowerShell invocation fails when running in context of “PowerShell on Remote” task
  • #17 Update tool to recognize RM Server 2015.2

Benefits

The tool saved Payoneer a lot of time and it is the main reason for adopting the new RM without waiting for future releases that will make the new RM similar to the old one functionality wise. See the Release Management Planning Update 2016 H2 blog post for more details.

Comments (0)

Skip to main content