As a tester, the time we spend on each task is important, we need to keep identifying solutions that can save our time and effort. I will discuss one such solution we implemented during automated build deployment.
There are many tasks that we repeat several times, this will be exciting first few times when this task is new but once you get used to it, it becomes repeatative.
As part of my work I am responsible for deploying the client side builds to web server. There is a fixed process that needs to be followed always, this situation is appropriate for automation and the good thing is, it does not need much time and effort. First, I will highlight the manual process that is followed to achieve this task.
1.Checkout the code from svn with a specific revision number to folder in local machine
2.Run a shell script to minify the buid
3.Rename the minified build as per the naming convention
4.Deploy build to server using any of the ftp clients, we used winscp.
This process takes 15-20 mins for each build
If there is a mistake in build like
Incorrect revision no
Incorrect svn url
This process needs to be repeated
The solution was simple, we used a shell script to automate this whole process. the only things we needed was svn commands, winscp commands & dos commands
This helped us reduce total deployment time from 15-20 mins to 5 mins
With the help of systems team we made this solution more optimized and brought down the deployment time from 5 mins to 1-2 mins
The systems guy introduced us to TeamCity which is a continous integration server, it has a lot of features that can help us achieve automated build deployment.
Here are the general steps for setting up the deployment taken from teamcity site, This can vary based on your requirement.
- Write a build script that will perform the deployment task for the binary files available on the disk. (e.g. use Ant or MSBuild for this)
- Create a build configuration in TeamCity that will execute the build script.
- In this build configuration configure artifact dependency on a build configuration that produces binaries that need to be deployed
- Configure one of the available triggers if you need the deployment to be triggered automatically (e.g. to deploy last successful of last pinned build), or use "Promote" action in the build that produced the binaries that need to be deployed. Consider using snapshot dependencies in addition to artifact ones and check Build Chains tab to get the overview of the builds.
- If you need to parametrize the deployment (e.g. specify different target machines in different runs), pass parameters to the build script using custom build run dialog. Consider usingTyped Parameters to make the custom run dialog easier to use.
- If the deploying build is triggered manually consider also adding commands in the build script to pin and tag the build being deployed (via sending a REST API request).
You can also use a build number from the build that generated the artifact.
Build Script could be shell script or ant This build script will have the above manual process in form of commands, once the configuration is completed you can just click a "run" button from the dashboard, deployment is done automatically and the results displayed on dashboard. There is also facility to check the log file to debug if deployment fails.
You can also add auto sending of emails if a build is deployed successfully to the relevant user group. This can be added in script.
There is also facility to pass parameters to build script