ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 6, June 2014 Efficient Automated Build and Deployment Framework with Parallel Process Prachee Kamboj1, Lincy Mathews2 Information Science and engineering Department, M. S. Ramaiah Institute of Technology, Bangalore, India 1, 2 Abstract: Continuous integration has been in theory for a long time but successful practicing is still a dream. To resolve the integration problems and increase the customer satisfaction, it is important to follow the practice of continuous integration in software development. Doing manual build and deployment regularly results in lot of time consumption and thus becomes an inefficient process. This paper proposes architecture for build and deployment by following best practices. It aims to fully automate the build process by using some available tools for source management, binary management and compilation. Build architecture gives a method to integrate all tools in build server. Successful completion of build is followed by deployment. This paper also proposes a deployment architecture which is common for all development environments. Deployment architecture states three steps, required to do the deployment and also proposes optional features to enhance the deployment process. Keywords: Automation, Build, Continuous Integration, Deployment, Parallel I. INTRODUCTION Software development is done in different environments. Generally industry follows four environments which are Development, Quality Assurance, Stage, and Production [1] . Before delivering the software to the customer it is essential to test the software and ensure the quality of Figure 1: Build and Deployment automation for different development software. The environments should not intersect as the Environments activities between each group in software development This paper proposes a new build and deployment should not interfere with one another. The development framework suitable for enterprise. Framework has focused environment is used for developing the application. Users on automation and introduction of parallelism to increase in development environment can expect the application to efficiency and reduce response. Build and deployment change often and be broken for extended periods of process is same for all environments to avoid confusion time. The Quality Assurance environment is used for for the users. testing. The staging environment is the dummy of production environment and is used to test the application II. BUILD for production environment without having users accessing the application. This environment is used to A. Build Steps make sure security settings are correct and that other Conventionally building software is referred to as services on the user computer or server do not interfere converting the source code into executable file [2]. In this with the application. The production environment is the era of software development getting mature, it needs to do environment where the users actually run the live some more tasks which makes the build stable and more application. Changes to this environment happen in meaningful. It is an end-to-end process that comprises of periodic updates to the software after the application many steps as shown in figure 2 below. changes have passed through the previous three environments. The other environments help ensure that the application is well tested and stable when it is released. Build and deployment is an integral part of any software development process. Software build refers to the process Figure 2: Block diagram of Build Steps of compiling the source code into a form which can be Creating a Clean Build Location prepares an environment deployed in a computer or a server. In an environment like for the build process to execute. Same source code file can development and quality assurance, build and deployment be modified by many users simultaneously. To maintain can be done many times in a day also. It makes sense to consistency, user’s files are tagged. Original copies of all make whole build and deployment process automated. source files are labelled in baseline separately. Labelling Automation is being adopted by many organization for its the source code approves the source file which is unmatchable advantages compared to manual process. Fig consistent among all files. Running Pre-Build Tasks 1 shows the block diagram of build and deployment includes capturing metadata about the code like setting the automation on different development environments [1]. version number for the output file, etc. Compiling the Code & Linking Libraries includes Unit and integration Copyright to IJARCCE www.ijarcce.com 7009 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 6, June 2014 testing is also done before compilation to ensure manually to initiate the build so that steps 3 to 7 are reliability. Other types of testing can be done depending automated. on the application requirement. At the end, it outputs the The key component of this architecture is to set a build executable code which is ready for deployment. server. Build server is the next step to have a stable and robust build. [9] This server is the heart of the whole build B. Build Automation process. Build server performs all major tasks like pulling Agile software development is a proven method adopted down the latest labelled source code, acts as a continuous by many enterprises. Among the basic principle of agile integration server by installing build tool which triggers software development methodology is contiguous build automatically, does the compilation of the source integration [4] [5]. Continuous integration is a practice based code etc. Build server will always have the clean code of on principle of detecting integration error in early stage. It the source code label. Build server will also publish the is practiced by integrating developers codebase many binary to binary repository management system. It even times in a day. Usually integration is done at least on daily resolves the encoding dependency problem for binaries. basis. Build is a repeated process, done in every Software development process produces mainly source environment before going live for the users of application. code and binary artifacts (or executable code) which serve Even if one is not practicing continuous integration, build different purpose. Source configuration management automation is required. Build automation helps in system is commonly required where there are multiple improving the software quality, reduces compile and developers working on the same project concurrently on linking the library time, eliminates redundant tasks [3], same set of source file. It helps in source control, change minimizes broken builds occurrence, reduces key management, and in version control. It keeps the track of personnel dependencies, improves traceability through the changes happening in the file, assigns a temporary logging the build steps etc. number to the users file and keeps the original file preserved. When a developer is satisfied with the source file then source file is checked in to source configuration C. Build Architecture management server to create a new version of the file. If many users check in the file at same time then the source Figure 3 explains the build process. In build architecture configuration management server combines the changes steps 2 to 7 can be automated if one is practicing and is merged to create a new version of file. continuous Integration, else user can trigger the build Figure 3: Build Architecture There are many ways to trigger build but as this paper In build server, build tool creates a clean build location for talks about continuous integration practice, this step the build and deletes old temporary build space that is not should be automated. Ideally as soon as developer required for the current build. Build tool is configured to commits the source code in source code repository, build get the latest source code in the build server from source should be triggered. Build can be scheduled for nightly configuration management server. This source code is basis and there should be scope of manually triggering the stored in build server and it should not be modified further build. After this all steps should be automated and in the build server. Compiling the code is the major step executed sequentially. and the most time consuming step. Code is compiled base Copyright to IJARCCE www.ijarcce.com 7010 ISSN (Online) : 2278-1021 ISSN (Print) : 2319-5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 3, Issue 6, June 2014 on the compiler required by the application programming language. Unit testing can also be performed as part of this step. After successful completion of the testing, it should be archived with a meaningful label on it. It should have some numbering or a time stamp value to distinguish the file from the other builds. Once the build is completed, archived file should be send to the Binary Repository Management server at a common location for all the builds of this application. Doing so helps other team members to download the file when required. If a build fails concerned person should be informed about the same. Build logs are also generated to find the reason of the build failure. III. DEPLOYMENT A. Deployment