{"id":62,"date":"2016-03-22T01:39:12","date_gmt":"2016-03-21T23:39:12","guid":{"rendered":"http:\/\/erez.heilweil.com\/alm\/?p=62"},"modified":"2019-02-12T01:46:48","modified_gmt":"2019-02-11T23:46:48","slug":"deploying-ivr","status":"publish","type":"post","link":"http:\/\/erez.heilweil.com\/alm\/2016\/03\/22\/deploying-ivr\/","title":{"rendered":"Deploying IVR"},"content":{"rendered":"

I was asked to build<\/a> a full ALM<\/a> process for the company Interactive voice response (IVR). IVR is consisted of  lots of files (1.5 GB) mostly binaries (Voice files) and a Genesis studio projects.  I was asked to be able to keep track on changes and automate the process of keeping the file changes at it’s minimum. I need to emphasize that the IVR process Today is manual and is consisted of copying files manually and organize requirements and changes in excel files.<\/p>\n

Since I am not familiar with the IVR development my plan<\/a> was first to add all files to the source control and keep track on file changes.  Doing so I could have seen that all changes are under four main folder and by tracking these folder and and adding comments and work items I could implement a planing<\/a> and coding<\/a> phases. Still coding<\/a> is not full since i lack the ability to automate the Genesis studio  compilation process which has no command line interface. Therefore, I decided to keep the compiled files under the source control as well. I have a vague idea of how to compile the Genesis using visual automation test<\/a> tools, but i will keep it for later development.<\/p>\n

So now I left with a build<\/a> process. In all common build<\/a> process I will use  compiling and keeping the output files and of course label the code. but here since I have a lot of files and some of them are huge So I decide not to copy files on build<\/a> but only to keep a text files consisted of all the changed file names, and of course labeling. by using this method I conserve allot of storage and still keep anything i need for the deployment<\/a> phase.<\/p>\n

In my deployment<\/a> process  I always keep track on the previous deployed version. This is done by keeping TFS text file containing all build  data which include  the label details as well. So now I have my current deployed build label and the the label that I want to deploy and all what left is to go over all the labels between and get their changed file names. By joining all the file names i can get a list of all files that has changed between these labels.  Now it’s time to sync all files to the correct label and then deploy them to the required environment. by doing this i don’t really  need to keep many files which are not needed to in the build process and all the changes are kept automatically and not manually on an excel file.<\/p>\n

One downfall with this process is the going backward process which need to deploy a previous version. In ordinary process I will go to the build with the required label and hit the deploy button but here I can only go forward since previous label contains only the changed files from it’s previous label and not from this label which is more advanced. This means moving to a new branch from the required label and running the  build phase. by doing so the difference between these labels will consist of all files that need to be replaced in order to deploy.<\/p>\n

So this is in short how to make a long and manual tedious process with lots of files as simple “click of a button” process to the the IVR team.<\/p>\n

 <\/p>\n

 <\/p>\n\n\n

\"\"\/
Now, make a process out of that…<\/figcaption><\/figure>","protected":false},"excerpt":{"rendered":"

I was asked to build a full ALM process for the company Interactive voice response (IVR). IVR is consisted of  lots of files (1.5 GB) mostly binaries (Voice files) and a Genesis studio projects.<\/p>\n

Read More<\/a><\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":"","jetpack_publicize_message":""},"categories":[5],"tags":[6,13,7,14,11,12,10],"class_list":["post-62","post","type-post","status-publish","format-standard","hentry","category-work-related","tag-build","tag-coding","tag-deployment","tag-genesis","tag-ivr","tag-planing","tag-tfs"],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p7mMlm-10","jetpack-related-posts":[],"_links":{"self":[{"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/posts\/62","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/comments?post=62"}],"version-history":[{"count":5,"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/posts\/62\/revisions"}],"predecessor-version":[{"id":138,"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/posts\/62\/revisions\/138"}],"wp:attachment":[{"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/media?parent=62"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/categories?post=62"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/erez.heilweil.com\/alm\/wp-json\/wp\/v2\/tags?post=62"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}