Continuous Integration | World Of Agile

Continuous Integration | DevOps Training - World Of Agile In Continuous integrations, all the developer work is merged to the main branch several times a day. This helps in reducing integration problems.

In Continuous integration we try to minimize the duration for which a branch remains checked out. A developer code gets early feedback on the new code added to the main repository by using Continuous Integration.

Implementing Continuous Integration The practice of Continuous Integrations (CI) relies on certain prerequisites being in place.

Version Control Everything in your project must be checked in to a single version control repository which may include ● ● ● ● ● ●

Code Tests Database Scripts Builds Deployment scripts Anything required to create, install, run and test your application

An Automated Build You must be able to start your build from the command line. You can start off with a command-line program that tells you IDE to build your software and then run your tests, or it can be a complex collection of multistage build scripts that call one another. Whatever the mechanism, it must be possible for either a person or a computer to run your build, test and deployment process in an automated fashion via the command line.

IDEs and CI tools have become pretty sophisticated these days, and you can usually build your software and run tests without going anywhere near the command line. However, you should still have build scripts which can

be run from command line without your IDEs. This is since you would need to run your build process in an automated way from your CI environment.

Agreement of the Team CI is a practice, not a tool. It requires a degree of commitment and discipline from your development team. You need everyone to check in small incremental changes frequently to the main line and agree that the highest priority task of the project is to fix any changes that break the application. If people don’t adopt the discipline necessary for it to work, your attempts at continuous integration will not lead to the improvement in quality that you hoped for.

Best Practices of Continuous Integration Some of the Best Practices of Continuous Integrations are ● Build Automation : In CI, we create such a build environment that even with one command build can be triggered. This automation is done all the way upto the deployment to the Production environment. ● Main Code Repository: In CI, we maintain a main branch in the code repository that stores all the Production ready code. This is the branch that we can deploy to Production any time. ● Self-testing Build : Every build in CI should be self-tested. It means with every build, there is a set of tests that runs to ensure that changes are of high quality. ● Everyday commit to baseline : Developers will commit all of their changes to baseline everyday. This ensures that there is no big pileup of code waiting for integration with the main repository for a long time. ● Build every commit to baseline : With automated continuous integration , every time a commit is made into baseline, a build is triggered. This helps in confirming that every change integrates correctly. ● Fast Build Process : One of the requirements of CI is to keep the build process fast so that we can quickly identify any problem. ● Don’t Check In on a Broken Build : The cardinal sin of CI is checking in on a broken build. If the build breaks, the developer who broke it has to build it and get it working at the earliest. ● Always run all commit tests locally before committing: Running a commit tests locally is a sanity check before committing to the

action. It is also a way to ensure that what we believe to work actually does. ● Production like environment testing : In CI, we maintain a production like environment also known as pre-production on staging environment, which is very close to the Production environment. .We perform testing in this environment to check for any integration issues. ● Publish Build Results : We publish build results on a common site so that everyone can see these and take corrective actions. ● Deployment Automation : The deployment process is automated to the extent that in a build process we can add the steps of deploying the code to a test environment. In this test environment all the stakeholders can access and test the latest delivery.

Benefits of Continuous Integration ● CI makes the current build constantly available for testing, demo and release purposes. ● With CI, developers write modular code that works well with frequent code check-ins ● In case of a unit test failure or bug, the developer can easily revert back to the bug-free state of the code. ● There is drastic reduction in the chaos on release day with CI practices ● With CI, we can detect Integration issues much earlier in the process ● Automated testing is one very useful side effect of implementing CI ● All the stakeholders including the business partners can see the small changes deployed into the pre-production environment. This provides early feedback on the changes to software. ● Automated CI and testing generates metrics which helps in improving the development options.

Continuous Integration and Distributed Teams Using continuous integrations with distributed teams is, in terms of process and technology, largely the same as in any other environment.

However, the fact that the team is not sitting together in the same room – perhaps not even working in different time zones does have an impact in some other areas. ● For Distributed teams within the same time zone, the continuous integration is much the same.

● For distributed teams in different time zones, there are more issues to deal with. If the team in the USA breaks the build and goes home, this can be a serious handicap for the team in India. The process does not change but the importance of adhering to it is magnified. ● Some of the more powerful continuous integration servers have facilities such as centrally managed build farms and sophisticated authorization schemes that allow you to provide continuous integration as a centralized service to large and distributed teams. ● It is also worth considering moving to a distributed version control system such as Git that allows people to check in even when there is no link to the conventionally designated “master” server. In Git, contributions are made first by forming the repository of the project you wish to contribute to, making your changes and then asking the owners of the original repository to pull your changes if they are working all-right. ● Having a local version control system can also be an option in the worst of circumstances. However it should be avoided as much as possible.

For More Information, Follow the Links belowWebsite - https://worldofagile.com/ Facebook - https://www.facebook.com/Fascinating.World.Of.Agile/ Twitter - https://twitter.com/WorldOfAgile LinkedIn - https://www.linkedin.com/company/world-of-agile/ YouTube - https://www.youtube.com/c/WorldOfAgile

Tags - Scrum Master Certification, Scrum Master Certification Mumbai, Scrum Master Certification Pune, Certified Scrum Master Training in Delhi, Scrum Master Certification Kolkata, CSPO Certification, Agile Scrum Master Certification Online, Advanced Certified Scrum Master Training, DevOps Training, Prince2 Certification, PMP Certification, ITIL Certification