Category Archives: Work Related
It’s a lonely world.
Configuration managers usually find themselves alone at the company. In most companies I worked alone or had the opportunity to lead or work with one more companion. So “who you gonna call?” who has answers when you need to consult?
Locked file and Launcher file
At LeumiCard Customer services there are some programs running straight from a shared network folder. This has been done long before I started working there and was a real problem I encountered while trying to implement the deployment process, since while people are using the program the files are in use and cannot be replaced.
Only improvise with what you got
A good friend of mine once told to “only improvise with what you got” and behind the obvious part of this sentence there is a real methodology. LeumiCard was the first time for me at a really big corporate. I needed to adjust my self to the new rules. In small companies you can do whatever you fill like. For example if you need a Jenkins you request a server, get it in 5-10 minutes install everything and grant it the required permission. At big corps you get to fill forms and lot’s of them. I had to wait two weeks for my first build server and then more forms to fix access permission. In order to make thing more complex no internet access is allowed on company networks, which means there is full process to get an software inside our air gaped and secured network.
When I started to working on the deployment process at LeumiCard I tried to improvise only with what I get. Meaning TFS 2008 which I quickly upgraded to 2012, Nolio which later changed it’s name to CA Lisa which handled all environments, permissions and server connections, and finally powershell which is installed on all servers. So at first I tried using Microsoft Release Manager which was part of our MSDN License but when I started configuring it I encountered the overhead in configuring the different environments, permission and servers. But I had to stop when i figured I had to do that for each project and I had more then a hundred. So I was digging for a solution that will provide me a generic connection between all the tools I get and which has to be approved by the company Data Security. In my searches I encountered a small open source program called TFSDeployer. I downloaded the code passed it trough all channels and regulations and implemented it on my build server.
The TFSDeployer software main purpose is to listen to TFS Build quality changes and do something according to a predefined xml. For me this was the magic tool that lead from the build process under TFS to deployment Done by Nolio. So what I did first was to create the right quality name and write the appropriate powershell script which runs the Nolio process (using command line) with the correct parameters. At first I did it all hard coded on one project in order to figure out and pass all security and permissions issues. I get it working meaning going to the build choosing “Deploy To Test” and having TFSDeployer figuring the string and running a powershell script which copy from the build drop folder and them having Nolio move it to the requested environment. Then I had time to make it as generic as possible, so I removed all the build details from the powershell script because I had them from the build page which triggered the quality change using TFSDeployer. So I was left only with Nolio parameters which I moved to the TFSDeployer XML. The result was a generic powershell script without any build or environment reference which was suitable for all projects and environments.
After having a generic deployment process I kept on improving it and adding different steps such as code review enforcement (A feature which is missing in TFS) and also a checklist requirement form before deploying to production. So in this process all i was left to do is add functions to the powershell script and add the parameters into the huge XML file which is really the decision making mind behind all the deployment process.
Example of TFSDeployer process for test deployment:
- build quality changes to “prepare for Test” by developer
- Powershell scripts get’s what to copy from the build drop folder into a preparation folder
- Powershell scripts creates code review work item assigned to team leader with all changesets since last build deployed at test.
- build quality changes to “Deploy To Test” by developer or team leader
- powershell checks if code review work item is closed
- powershell runs Nolio with the appropriate builds parameters taken from the TFSDeployer XML.
- Nolio copy the process to the correct server with the appropriate permissions.
This is how I improvised only with what I had and accomplished the most out of it with keeping in mind the flexibility I needed in order to answer the hundreds of projects under my TFS.
Go with the flow
In all the companies I worked as configuration manager I did my best to go with flow. The flow in my case always were the developers. I know that by interfering with the development process nothing can be achieved and it will all backfire at me. So in every job I started I examined the developers work and did what ever I could to improve their most frustrating process first.
Deploying IVR
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. 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.
Since I am not familiar with the IVR development my plan 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 and coding phases. Still coding 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 tools, but i will keep it for later development.
So now I left with a build process. In all common build 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 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 phase.
In my deployment 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.
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.
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.
.net 1.1 and TFS 2012
I recently was asked to add a .net 1.1 legacy solution to our TFS 2012 build and deployment process. Just to be clear .net 1.1 released on , 2003-04-24 same year google started spreading. So to my surprise all help regarding .net 1.1 which is very slim stated upgrade to .net 2.0 Visual studio 2005 in order to at least have msbuild support and then you can add msbuild tools that support this kind of tools.
