Subscribe by Email

Sunday, February 17, 2013

Ensuring that builds are posted in the locations where people are located

In today's world, applications are developed all over the world, in the sense that if you look at a product development team, it will have members located all over the world. So, I have worked on several products where some developers are based in a location in India, some are based in Germany, and some others are based in multiple locations in the United States. Now, one can argue that this would be confusing and not an ideal state, but the fact remains that because of reasons related to costs, acquisition of companies (I once had a colleague who was absorbed into the company as part of one product, and then assigned to another product based on a resourcing decision - with the associated issue being that the original product was being developed out of his location, but for the new product where he was now associated, he was now a remote worker), and the need to meet the geographic needs of talented people who would otherwise not join, teams can get geographically dispersed. So, let us take it for granted that such teams exist, and consider some of the problems that can happen with such teams. We will talk about coordination & communication issues in a separate topic, but one major issue with teams working on large products is the sheer size of getting the builds to them on a regular basis. Consider teams that work on applications such as MS Office, Photoshop, CorelDraw, and many other such products, the sheer size of the application builds can be upwards of 1GB+.
When you are working on an application development program, it is important to work on the newest version of the application. Typically for most product development applications, this means that a new build will be generated every day, available for the developers and testers. This allows the testers to test with all the fixes that have been made the previous days, and also ensures that developers have the same confidence that their fixes are in, and are being tested regularly. Now this sounds fine when everybody is located in the same geographic location (I mean there are other issues related to ensuring that the build is a solid build, that build failures are detected early, and so on), but gets more challenging when members of the development team are located in different locations. Given the size of some applications (as I mentioned above, they can be 1GB or more sometimes), even with very fast connections, it can take time to ensure that these builds are delivered to the remote locations within a short period that they are available in the location where they are generated. And when you consider locations such as those in India, the availability of fast broadband lines is not of the same assumed speed as those available in the United States (or which can actually be more expensive). So, there needs to be a lot of thought given to how these builds will reach the different geographic locations. All this rules out the possibility of transferring builds manually to the different geographic locations; instead what needs to be done is to add a sequence of commands in the build script near the end that check for whether the build has been made, that the sequence has not showed any obvious errors (and if possible, incorporate some smoke tests to ensure that the build launches and works fine) and then does an automatic ftp transfer to default directories on the other geographic locations. The reason for incorporating smoke tests is to ensure that you do not start sending out builds to the other locations that are not possible to use. Even in such cases, you will find that once in a while, there will be failures and build will not be available, but in most cases, you will find that you needs will be met.
However, there is a complication that can happen about setting the timing of the build delivery across multiple locations, and I will cover that in a forthcoming article (link to next article - TBD).

No comments:

Facebook activity