Continuous Integration and Deployment
It has been more than 2 months since I have entered a new phase of my life and as a different species, at that(since I am into monkey business!).
Even before joining Langoor I knew that I will have to face many challenges here but I always knew that the amount of knowledge I will be able to grab here will be invaluable in terms of my growth as an individual and a professional.
One of the best things I have come across here is the chance of exploring and implementing an agile methodology – ‘Continuous Integration and Deployment’ along with ‘Automated Testing’. Believe it or not if you dig in deep enough, you will surely get to know how easy and robust it makes the whole process of development. It makes life easy for developers, very easy!
All first timers ask- “would Continuous Deployment make much difference to our current ongoing process?” But believe me, once you get started, then the next reaction would generally be “How would my life as a developer possible without this?”
So now the most obvious question that I should’ve written about sometime ago – What is Continuous Integration (CI)?
Integration is a very long, unpredictable and sometimes unreliable part of Software Development. This happens so because sometimes the changes made by a member of the team may affect other components, disrupting the entire flow. So, CI is a practice where members of a team integrate changes very frequently, thus leading to multiple integrations.
Each integration is verified by various automated builds and tests at various stages, to detect the faults as soon as the Integration is done. Since the errors are detected early, CI significantly reduces integration problems thus allowing a team to develop cohesive software more rapidly.
How does Continuous Integration work/happen?
CI follows a step by step procedure that allows for simple execution-
• A Code Repositorty – A code repository is a must! It helps you to revise control system for a project’s source code and it should also support atomic commits, i.e. all of a developer’s changes may be seen as a single commit operation.
• Build Automation – There should be a provision of automating the process of creating a build of the system from the fresh checkout.
• Self Testing Mechanism for each ‘Build’ – With each build there should be a self-testing mechanism. Once the code is built, there should be various test cases which check if the system is behaving as the developers expect it to behave after integration since many times it is possible that an error of one developer may disrupt the flow of whole system.
• Seeing the results of latest build – Each build should generate a proper report giving details if the build breaks due to disapproval by the testing server or some other reason. This helps to identify if the latest changes in code create problems for entire flow or not.
• Automated Deployment – Once the build finishes and the testing server approves the build, then the changes need to be reflected in Production Server. Scripts can be written for this to do this job automatically or pushing the changes with just one command or click.
This process is something that we have adopted here to simplify the whole process of change management in a development environment. However, the cumbersome process is a team-work that all of us have enjoyed and loved putting it together.