Continuous Integration (CI) is rapidly becoming an integral part of software development process as it makes our monotonous and repetitive tasks a little less grindy. CI is a project development practice where developers integrate code into a shared repository frequently. Each Integration is then verified by an automated build that allows the team to detect problems in an early stage. This post will walk you through the continuous integration with Jenkins and GitHub. Here we will install Jenkins, create Jenkins task and then configure it with GitHub. How does Continuous Integration differ from Continuous Delivery? A CI service compiles and tests a full application (possibly by running the application in an emulator). Continuous delivery also pushes this compiled application to a repository, for example, for alpha testers to use and provide early feedback. CD builds are automatically deployed through to the production environment and can also be used for broader beta testing.
Jenkins is an incredibly powerful tool for DevOps that allows us to execute clean and consistent builds and deployments that mitigate the risks of a manual execution plan. But creating the jobs within Jenkins to do this work can be labor intensive, manually updating those jobs is often error-prone, and tracking changes to those jobs is tedious at best. How do you create a Job in Jenkins? Go to Jenkins top page, select “New Job”, then choose “Build a free-style software project”. This job type consists of the following elements: optional SCM , such as CVS or Subversion where your source code resides. optional triggers to control when Jenkins will perform builds. some sort of build script that performs the build (ant, maven, shell script, batch file , etc.) where the real work happens optional steps to collect information out of the build, such as archiving the artifacts and/or recording javadoc and test results. optional steps to notify other people/systems with th