CSC/ECE 517 Spring 2015/ch1a 6 TZ
Snap CI
Snap CI is a hosted continuous integration and continuous delivery service.
Background
Continuous integration (CI) is the practice of merging all developer working copies with a shared mainline several times a day. It was adopted as part of extreme programming (XP). The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP.
CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development (TDD). Initially this was conceived of as running all unit tests in the developer's local environment and verifying they all passed before committing to the mainline. This helps avoid one developer's work in progress breaking another developer's copy.
Later elaborations of the concept introduced build servers, which automatically run the unit tests periodically or even after every commit and report the results to the developers. The use of build servers (not necessarily running unit tests) had already been practised by some teams outside the XP community. Nowadays, many organisations have adopted CI without adopting all of XP.
In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying quality control in general — small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes.<ref>http://en.wikipedia.org/wiki/Continuous_integration</ref>
Example
Getting started on Snap CI.
Step1: Sign in
To sign up with Snap, visit Snap CI and click in the Sign in with Github link at the top. When you sign in, GitHub will ask if you want to give a set of permissions to Snap.
Step2: Add your repository
Once you are signed in, Snap will present a list of all the repositories you have access to. You may only build repositories. If you are an administrator on any of those repositories, you may build that repository on Snap.
Step3: Config your build
When you select a repository to build on Snap, we will attempt to automatically detect some popular configurations for your build. We look for languages versions, build tools files, dependency managers and other conventions that may indicate how your build could be set up. In this guide we'll use a ruby repository, but we do support lots of other languages.
As most of the ruby repositories, this one uses a dependency manager tool call bundler and the rspec testing framework. Because of that, Snap automatically added the default command for each of them: bundle install --path ${SNAP_CACHE_DIR}/.bundle and rake spec respectively. Most of the times that would be everything needed to run your tests. However, there may be some tasks that are pre-requisites to it. In this specific build, we need to execute the command bundle exec foreman start &. It can be done simply by adding it before bundle exec rake spec.<ref>https://docs.snap-ci.com/getting-started/</ref>
Step4: Build
All that's left to do is click Build now and let Snap run our build.
Compare Different Continuous Intergration Tools
Common Continguous Intergration Tools
There are more than 30 continuous intergration tools designed to adapt to different platforms. I select several tools which can connect Github and relate to Ruby to compare.
| Name | Platform | License | Windows builders | Java builders | Other builders | Notification | IDE Integration | Other Integration |
|---|---|---|---|---|---|---|---|---|
| CircleCI | Hosted | proprietary | unknown | unknown | Ruby, Python, Node.js, PHP, Java | E-mail, Campfire, HipChat, CCtray | unknown | Heroku, GitHub |
| node.ci | Hosted | proprietary | unknown | unknown | Node.js | unknown | Amazon Web Services(AWS), GitHub, Bitbucket | |
| Codeship | Hosted | proprietary | no | Maven | Go , Java , Node.js, PHP, Python , Ruby | E-mail, Flowdock, Grove, HipChat, Web | no | CloudControl, Engine Yard, GitHub, Heroku |
| Continua CI | Windows | proprietary | Ant, Nant, FinalBuilder, MSBuild, Rake, Visual Studio, Powershell | Ant | Execute Program(command line) | E-mail, XMPP | no | GitHub, Bitbucket, Codeplex, Kiln, Team Foundation Server(TFS), FogBugz, Jira, NCover, Opencover, NUnit, DUnitX, jUnit, xUnit, NuGet, 7Zip |
| Drone.io | Hosted | Apache 2.0 | unknown | Ant, Apache Maven|Maven 2, Gradle | C, C++, Dart, Go, Node.js, Python, PHP, Ruby, Java, Groovy, Scala, Erlang | unknown | Heroku, Dotcloud, GitHub, Bitbucket | |
| Koality | Cross Platform, Private Cloud | proprietary | unknown | unknown | Command-Line | Email, HipChat, GitHub | unknown | Amazon Web Services, GitHub |
| Semaphore | Hosted | proprietary | unknown | Apache Maven 3 | Ruby , Java , Node.js, PHP, Clojure, Rake, Command Line | E-mail, Campfire, HipChat, Slack, Flowdock, Webhooks, Remote API | unknown | GitHub, Bitbucket, Heroku, Code Climate, Cloud 66 |
| Shippable | Hosted | proprietary | MSBuild, NAnt | Apache Ant, Apache Maven, Gradle | Ruby, Python, Node.js, Java, Scala, C Sharp, PHP, Go | E-mail, Campfire | no | GitHub, Bitbucket Heroku |
| Snap CI | Hosted | proprietary | no | Apache Ant, Apache Maven, Gradle, Android | C, C++, Clojure, Erlang, Go, Groovy, Haskell, Java, Node.js, Perl, PHP, Python, Ruby, Scala | E-Mail, Campfire, HipChat, Webhook | no | AWS |
| Solano CI | Private Cloud | proprietary | no | Apache Ant, Apache Maven, Gradle | C, C++, Clojure, Go, Java, Javascript, Node.js, PHP, Python, R, Ruby, Scala, Command Line | E-Mail, Campfire, HipChat, Flowdock, Slack, Webhook, CCMenu | no | GitHub, GitHub Enterprise, Bitbucket, Heroku, Amazon Web Services(AWS), Git, Mercurial |
| Strider | Node.js | freeBSD | no | no | C, C++, Clojure, Erlang, Go, Groovy, Haskell, Java, Node.js, Perl, PHP, Python, Ruby, Scala | no | GitHub, Bitbucket, Heroku, GitHub Enterprise, Git | |
| Travis CI | Hosted | MIT | no | Apache Ant, Apache Maven, Gradle | C, C++, Clojure, Erlang, Go, Groovy, Haskell, Java, Node.js, Perl, PHP, Python, Ruby, Scala | E-Mail, Campfire, HipChat, IRC, Slack | no | GitHub, Heroku |
Snap CI vs. Other Tools
Different Endpoints
Many Continuous Integration(CI) tools has this feature, that is, building and running tests when a change happens. However, Snap augments this with the idea of a Deployment Pipeline as stated on Part II of the Continuous Delivery.
What this means is while most Continuous Integration tools consider CI to be the endpoint (or maybe allow you to configure an automatic deployment), running tests is but the start of the journey in Snap.
Continuous Integration - The automated build and test of your software when a change is made by anyone on the team, with all work happening on a shared branch. Continuous Delivery - The ability to keep your software shippable at any time. Have a rigorous set of automated tests and robust deployment scripts and tools.
Stages
Stages are a set of logically related commands. To confidently say that your software is production ready, you need to look it at from multiple different angles. Unit tests, code formatting, functional tests, security checks, performance tests and so on. On more advanced projects, this might also include deployment of the software to testing environments and the execution of either automatic or manual tests against these deployed testing environments. Stages model each of these activities. Your software goes through these stages, one by one, and can be considered “good for production” when it pass all of them. On the flip side, when a stage fails, it reveals that an aspect of the software’s quality has failed its test for production readiness. When a stage fails, the pipeline is stopped and the team members are notified about the failure. Since there is a logical organization of these steps, when one fails, the team can quickly identify in which set of commands the failure has happened. This results in much faster feedback than would otherwise be possible.
The ability to organize these automation steps allows you to separate different concerns when preparing your software to be deployed to production. Snap’s support for deployment pipeline lets you create stages and also shows exactly how far each set of changes made it down the pipeline.<ref>http://blog.snap-ci.com/blog/2014/07/22/why-snapci-and-travisci-are-not-the-same-thing/</ref>
Deployment
At the end of a series of stages you can deploy your software to production. However most development teams do not jump to production after all automated tests pass. Instead, they use an environment similar to production for further testing and verification; usually called Staging or UAT (short for user-acceptance-testing). An important aspect here is to control what, where and when things get released. Coming back to the Continuous Delivery definition above:
Continuous Delivery - The ability to release your software on demand, with high quality and low risk; most often achieved by pervasive automation.
The “on demand” part of the definition translates to a “manually triggered stage” on Snap:
What this means is that this stage, called “publish”, won’t be executed as soon as the prior stage completes successfully but only when someone manually triggers it by clicking it. In this particular example this means that any change made into the project won’t be put into production automatically, but only when you want to. You can have any number of manual stages, and between them, automatically triggered stages. This is a key part of this feature. It gives you the flexibility to create deployment automations that exactly as simple or as complex as the needs of your business and your software. Manual stages can be triggered multiple times. This means you can deploy old versions of your application. But in order to do that robustly, it is important to configure artifacts.
Artifacts
Each stage executes a series of commands to verify your software. Once this is done, you don't have to create compilation artifacts again, such as packagesm, binaries. This is where artifacts help. You can ask Snap to save the contents of one or more directories in your build as an artifact directory. Snap will then save and restore the contents of this directory for each stage.
As result, when you have a manual stage that deploys to production, you can have it deploy the exact same binary which went through all the previous stages of this pipeline, regardless of how far back in history the pipeline was initially triggered. Recompiling, repackaging or more generally, recreating your artifacts can be problematic, as small changes in the environment could subtly impact how your software is packaged resulting in errors that are hard to track down/diagnose. Reusing artifacts eliminates this whole class of problems.
Artifacts are also helpful for verifying and debugging. By maintaining a history of your packages; developers, quality analysts, security audit folks and others can retrieve a specific version of your software and test it knowing that it is exactly the same software as in any given environment.
Different Branches
If different teams work on the same code but are split by branches, we can’t assume that they are integrating these changes continuously. Even when they are, the state of the individual branches is not visible to the team at large. This lack of visibility means that potential conflicts are not highlighted early and we are merely postponing their resolution.
This, of course, doesn’t mean that you shouldn’t use branches; just that they should be as short lived as possible. Snap has a solution to help out on these code integrations and highlight when two or more streams of work are diverging. When Automatic Branch Tracking and Integration Pipelines is enabled, Snap will not only execute the pipeline on the branch but will also attempt to do a local merge of the branch with the main tree and execute the pipeline against the merged code. Like so:
By the end of the pipelines you not only know that your changes pass through the pipeline but also it also will pass if you perform a merge with the main development tree. You are always aware if your changes are diverging from the main tree and in a position to take corrective action if required. Also, the whole team has visibility into the health of each branch.
Auditing and Compliance
Finally I will bring up a topic that may not be too popular among developers but is important for IT organizations in general, Auditing and Compliance. This topic is briefly handled on Continuous Delivery, Chapter 15, page 436. When you see that your deployment pipeline is ready for deployment. If you start the deployment, what changes will be published? To answer this question Snap give you the “Stage History” feature, where all changes between stages can be visualized. Here’s a example of some changes that will go into production if you deploy:
This history allow you to check all previous changes that got deployed and which will be deployed next. In addition, it also tells you who triggered the past deployments and when - giving the traceability many teams crave.
Narration
Conclusion
References
<references/>