Code Review, Build and Test can be automated to achieve Continuous Integration.
Code Review Tools
Every project’s repository is usually managed by some versioning tool. A choice for the versioning tool can be made, we can assume Git for now since its most popular. When the developer pushes his change, a build would be triggered. If the build is successful, then test job would be triggered. Its only after the tests pass, that this commit should be merged to the central repository. Typically the developer’s commit would also need manual review.
As a design principle for DevOps, the central repo should not have push/write access. He will commit to an “authoritative repository”.
- A decision from DevOps perspective must be made to choose the right versioning tool, managing of user’s commits to an authoritative repo and a code review tool. This will depend on the project’s requirement. Popular tools to be evaluated are Git, Gerrit, Teamcity.
- A DevOps engineer will have to setup and configure the tools. Eg – Git-Gerrit integration needs to be installed, setup, configured
Gerrit is a web-based code review tool built on top of the git version control system. It is intended to provide a lightweight framework for reviewing every commit before it is accepted into the code base. Changes are uploaded to Gerrit but don’t actually become a part of the project until they’ve been reviewed and accepted. In many ways this is simply tooling to support the standard open source process of submitting patches which are then reviewed by the project members before being applied to the code base. However Gerrit goes a step further making it simple for all committers on a project to ensure that changes are checked over before they’re actually applied.
Gerrit can be integrated with several Build Automation tools like Jenkins. It can also be integrated with Issue Tracking systems like RedMine. Eg: When a user commits his change for a bug #123 in RedMine, the bug in RedMine will get updated.
What is Gerrit? https://review.openstack.org/Documentation/intro-quick.html
Git-Gerrit configuration: http://www.vogella.com/tutorials/Gerrit/article.html
Implementing Gitflow with TeamForge and Gerrit – http://blogs.collab.net/teamforge/implementing-gitflow-with-teamforge-and-gerrit-part-i-configuration-and-usage
Generically Build Automation is referred to as writing scripts to automate tasks like compiling, packaging, running automated tests, deploying to production and creating documentation. This section however talks about simply building your code.
- Most projects already have build tools for them. Ant, Maven, Gradle.
- There might be a need for distributed builds. A build automation tool must be able to manage these dependencies in order to perform distributed builds.
- A DevOps engineer may have to write configuration scripts to build artifacts
Gradle can be integrated with Github. What we can achieve by this is GitHub would recognize Gradle build scripts and provide nice syntax highlighting.
Gradle can be integrated with any CI server. There is a good Jenkins plugin for Gradle. It can be integrated with TeamCity – an extensible build server. So essentially what we achieve is – “a user’s commit triggers a job in Jenkins, which uses Gradle to build the repository”.
Gradle can be integrated with some Repository Managers like Nexus. So if gradle builds an artifact successfully, it will have to be transferred to some remote location, artifacts of older builds need to be maintained, maintain common binaries across different environments and provide secure access to the artifacts. This is the role of a Repository Manager.
Integrating Gradle with Jenkins – https://wiki.jenkins-ci.org/display/JENKINS/Gradle+Plugin
Integrating Gradle with TeamCity – http://confluence.jetbrains.com/display/TCD8/Gradle
What is a Repository Manager – http://blog.sonatype.com/2009/04/what-is-a-repository/#.VFY5s_mUd8E
When user commits code and its successfully built and deployed to a test environment, the actual test jobs need to be started on that environment. The test jobs include unit tests as well as integration tests. The testing would most likely involve creating test VMs and cleaning them up after every tests. The test results would have to be relayed back to the developers and others at stake.
- From DevOps perspective we dont have a “test automation tool”. What we have is an automation framework, which will involve test automation. Hence this is one of the most important aspects of deciding on a DevOps automation tool.
- There are several CI servers, most popular being Jenkins. Travis and BuildHive are hosted services offering some additional options. The choice of a CI server will have to be made depending on several factors.
- The frequency of commits need to be estimated. Will you run tests after each commit?
- There are some tests that would run nightly
- A DevOps engineer will have to write configuration scripts which will trigger test jobs, create VMs, give back feedback, etc.
Eg: CI Server – Jenkins
Jenkins can be configured to trigger jobs that run tests. It can spawn VMs, clusters where the tests run. Depending on the tests, data volumes, you may have to consider using open source Jenkins or the Enterprise version.
Jenkins can be integrated with Git/Gerrit. So every push can trigger a build & test job.
Jenkins can be integrated with Code Analysis tools like Checkmarx.
Jenkins can be integrated with Repository Managers like Nexus.
Jenkins can be integrated with Issue Tracking tools like RedMine.
DevOps and Test Automation – http://www.scriptrock.com/blog/devops-test-automation
Case Study: Deutsche Telekom with Jenkins & Chef – http://www.ravellosystems.com/customer-case-studies/deutsche-telekom
Git, Gerrit Review, Jenkins Setup – http://www.infoq.com/articles/Gerrit-jenkins-hudson
Gerrit Jenkins Git – https://wiki.openstack.org/wiki/GerritJenkinsGit