CSC/ECE 517 Spring 2015/ch1a 6 TZ: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(77 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<font size="5"><b>Snap CI</b></font>
<font size="5"><b>Snap Continuous Integration</b></font>


Snap CI is a hosted continuous integration and continuous delivery service.
[https://snap-ci.com/ Snap Continuous Integration] (Snap CI) is a hosted continuous integration and continuous delivery service.


__TOC__
__TOC__


=='''Background'''==
=='''Background on Continuous Integration'''==
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 [http://en.wikipedia.org/wiki/Extreme_programming 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 [http://en.wikipedia.org/wiki/Test-driven_development 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.
Continuous integration (CI) is a software engineering practice that facilitates collaborative software development.  It is the practice of continuously evaluating how different developers' work would integrate, such as by running tests and performing builds several times per day.  It is often associated with [http://en.wikipedia.org/wiki/Extreme_programming extreme programming] (XP), but it can also be used with other approaches to software development.


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.
<blockquote>
CI was originally intended to be used in combination with automated unit tests written through the practices of [http://en.wikipedia.org/wiki/Test-driven_development test-driven development]. 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. [[#referencesAnchor|[1]]]</blockquote>


In addition to automated unit tests, organisations using CI typically use a build server to implement continuous processes of applying [http://en.wikipedia.org/wiki/Quality_control 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 [http://en.wikipedia.org/wiki/Software_quality 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>
In CI, developers commit their code to a build server, which automatically runs tests either periodically or after every commit, and reports the results to the developers via email or other methods. CI quality control has to be different from the traditional quality control processes of unit, system, and system integration testing.


=='''Example'''==
<blockquote>In addition to running the unit and integration tests, CI servers will 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 [http://en.wikipedia.org/wiki/Software_quality 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. [[#referencesAnchor|[1]]]</blockquote>
Getting started on Snap CI.


#'''Sign in'''
=='''Examples'''==
==='''Example 1: Getting started on Snap CI'''===


   <p>To sign up with Snap, visit [https://www.snap-ci.com/ Snap CI] and click in the Sign in with Github link at the top.
Snap CI is free to use for open source projects; for pricing for private projects, see [https://snap-ci.com/plans here].  It is easy to register your software project with Snap if your project is on [https://github.com/ GitHub].  Snap's [https://docs.snap-ci.com/getting-started/ web site] provides simple directions, which in summary are as follows:
   When you sign in, GitHub will ask if you want to give a set of permissions to Snap.</p>
 
===='''Sign in'''====
 
   <p>To sign up with Snap, visit [https://www.snap-ci.com/ Snap CI] and click 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 to access your repositories, which it requires in order to function.  Snap's [https://docs.snap-ci.com/managing-your-github-connection/ web site] says that "We never, ever commit code to your repository or look at your source code."</p>


[[File:1.Sign_in.jpg‎  |frame|center|Snap CI website]]
[[File:1.Sign_in.jpg‎  |frame|center|Snap CI website]]


==='''Step2: Add your repository'''===
===='''Add your repository'''====


   <p>Once you are signed in, Snap will present a list of all the repositories you have access to. You may only build repositories.  
   <p>Once you are signed in, Snap will present a list of all the public repositories on GitHub to which you have access. If you are an administrator on any of those repositories, you can build that repository on Snap.</p>
  If you are an administrator on any of those repositories, you may build that repository on Snap.</p>


[[File:2.Add_repository.jpg |frame|center|Your repository list]]
[[File:2.Add_repository.jpg |frame|center|Your repository list]]




==='''Step3: Config your build'''===
===='''Configure your build'''====


   <p>When you select a repository to build on Snap, we will attempt to automatically detect some popular configurations for your build.
   <p>When you select a repository to build on Snap, you can choose languages, databases, artifacts, secure files, dependency managers, and other conventions that may indicate how your build could be set up.  If you use an automated build tool for your software, this step may be straightforward, but otherwise it might require some effort.</p>
  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 [http://docs.snap-ci.com/the-ci-environment/languages/ other languages].</p>


[[File:3.Configure.jpg |frame|center|Configure your build]]
[[File:3.Configure.jpg |frame|center|Configure your build]]


===='''Build'''====
  <p>After completing the steps above, all that is left to do is click "Build now" and let Snap run your build.</p>
[[File:4.Passed.jpg |frame|center|Build passed]]
==='''Example 2: Heroku Deployment with Snap CI'''===
When you want to deploy applications on [https://www.heroku.com/ Heroku], you can easily make Snap test and deploy your applications. This section shows how to do so with a Ruby on Rails project.  The steps are as follows:
===='''Snap CI configuration'''====
  <p>Heroku currently requires your production database to be [http://www.postgresql.org/ PostgreSQL].  In Snap, you need to specify that you are using PostgreSQL.  <br/>Once you have Snap connected to your GitHub repository, you can click "ADD STAGE" to add a new stage named "DEPLOY".<br/>After that, you can choose a deploy tool, such as "Heroku (basic)".</p>
[[File:1.Snap ci connect heroku.jpg‎  |frame|center|Snap CI Configuration]]
===='''Set Heroku credentials'''====
  <p>When you click "Heroku Credentials", you can login to Heroku. Then Heroku will ask you whether you want to authorize or not. Click "Allow", if you want to authorize, and you will see your Heroku account shown on the Snap website, just like in the last picture in circle number 4.</p>
[[File:2.Snap ci connect heroku.jpg |frame|center|Set Heroku credentials]]
===='''Save and Run'''====
  <p>Then click the "Save" button at the upper-right corner of the Snap web page. Snap will automatically run, and you can check whether your application passes.</p>
[[File:3.deploy passed.jpg |frame|center|Passed]]
=='''Programming Language Support'''==
Snap supports [https://docs.snap-ci.com/the-ci-environment/languages/ many programming languages] and automated build systems for them.  For Java, for instance, it supports Java 6, 7, and 8, and, for build tools, Maven and Ant.  For Ruby, it supports bundler and rake.
It can automatically detect which build tools are used in the project, for certain build tools.  For instance, if a pom.xml file is present in a Java project, Snap CI can automatically configure itself for Maven.  (Apparently, the POM must be present in the top-level directory in the Git repository for Snap CI to detect it automatically.  If the Java project is in a lower-level directory, it is still possible to configure Snap manually to support Maven.)
=='''GitHub Integration'''==
Snap integrates closely with GitHub. GitHub is of course very popular for both open-source and closed-source software projects in many programming languages.  So, Snap focusing its efforts on GitHub makes sense for anyone using GitHub.
Snap by default triggers a build whenever a push is made to the user's GitHub repository, including any Git branch.  When a commit is made to a branch, it can also attempt to merge the branch with the master branch, and report the results.
Snap also tracks pull requests.  It runs a build to show what the result would be if the pull is merged.
An email is sent to developers whenever a build fails.
=='''Pipelines'''==
Snap allows a series of customized steps whenever it evaluates a build.  The steps together are called a "pipeline".  They can report different test information (pass or fail, the specific fail position) about your repository. What is more, you can even assign deployment of the software to testing or production environments, and the execution of either automatic or manual tests against these deployed environments.
Many continuous integration tools have the feature of building the software and running tests when a change happens. However, Snap augments this feature with the ideas of "deployment pipelines" and "continuous delivery".  Snap can in this manner perform more steps than other tools.
  '''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 easily packaged at any time. Have a rigorous set of automated tests and robust deployment scripts and tools.
Each step in the pipeline is at the core a series of command-line commands on the Snap server.  The console output is shown for each step.  If a step fails, the pipeline will halt; the later steps will not execute.
Both automatic and manual steps are allowed.  One would normally want to run most of the tests automatically with each Git commit, and perhaps deploy the software to a test environment.  However, a step can also perform a release of the software, which normally one would only want to run manually, not with each commit.  For instance, a step may deploy a web application to Heroku or Amazon Web Services.  It may also upload a software release file in its final form to a web site for distribution, such as to SourceForge or the project's GitHub releases page.  The final "publish" stage will not be executed unless someone manually triggers it. It means any changes made to the project will not be put into the production version automatically, which reduces the risks.


  <p>As most of the ruby repositories, this one uses a dependency manager tool call bundler and the rspec testing framework.
<blockquote>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.[[#referencesAnchor|[2]]]</blockquote>
Because of that, Snap automatically added the default command for each of them: <i style="background-color: #f0f0f0;">bundle install --path ${SNAP_CACHE_DIR}/.bundle</i> and  <i style="background-color: #f0f0f0;">rake spec</i> 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  <i style="background-color: #f0f0f0;">bundle exec foreman start &</i>. It can be done simply by adding it before  <i style="background-color: #f0f0f0;">bundle exec rake spec</i>.<ref>https://docs.snap-ci.com/getting-started/</ref></p>


=='''Support for Multiple Branches'''==


==='''Step4: Build'''===
Snap supports having different pipelines for different Git branches.  Each branch may thus be tested separately.
<blockquote>When [http://docs.snap-ci.com/working-with-branches/automatic-branch-tracking/ Automatic Branch Tracking] and [http://docs.snap-ci.com/working-with-branches/integration-pipelines/ 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. ... 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.
[[#referencesAnchor|[2]]]</blockquote>


  <p>All that's left to do is click '''Build now''' and let Snap run our build.</p>
[[File:Snap_ci_auto_branch_tracking.jpg |frame|center|Different Branches[[#referencesAnchor|[2]]]‎]]


[[File:4.Passed.jpg |frame|center|Build passed]]
=='''Comparison with Other Continuous Integration Tools'''==


=='''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.
There are more than 30 continuous integration tools designed to adapt to different platforms. Here are several tools that can connect to Github and build Ruby projects.
<center>'''Comparison of Continuous Integration Tools'''<ref>http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software</ref></center>
<center>'''Comparison of Continuous Integration Tools [[#referencesAnchor|[3]]]'''</center>
{| class="wikitable sortable" style="font-size: 80%; text-align: center; width: auto;"
{| class="wikitable sortable" style="font-size: 80%; text-align: center; width: auto;"


Line 167: Line 224:
| E-Mail, Campfire, HipChat, Webhook
| E-Mail, Campfire, HipChat, Webhook
| no
| no
| GitHub, Heroku, Amazon Web Services|AWS
| GitHub, Heroku, AWS


|-
|-
Line 204: Line 261:
|}
|}


Snap does have some limitations compared to other CI tools.  Notably, the only output from tests that Snap provides are output to the console or to files.  There is no way to see the test results in the Snap GUI.  Some other continuous integration tools provide web pages for viewing specific forms of tests.  For instance, in [http://jenkins-ci.org/ Jenkins CI], one can see whether individual JUnit tests pass, or view results from static analysis tools like CheckStyle or PMD, for which Jenkins has specialized plugins.


=== Snap CI vs. Other Tools ===
Snap certainly does allow deploying a web page from a command-line command. So, it is not necessarily a great limitation that it does not have a specialized GUI for tests if one has means of generating web pages with test results. Some build tools, such as Maven, can produce web pages with test output without much effort (such as by adding a few lines in the XML configuration file).
==== 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.
The website [[#referencesAnchor|[4]]] lets users vote on the best hosted continuous integration services. Although Snap CI does not get the highest votes, the web site still lists many advantages for it, such as:<br/>


  '''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.
<blockquote>1.Build artifact promotion and propagation<br/>
  '''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.
2.Ability to deploy to multiple environments<br/>
3.Manually triggered promotions from one environment to another<br/>
4.Track pipeline stage history</blockquote>


==== Stages ====
=='''Conclusion'''==
Stages are a set of logically related commands.
Snap CI has many advantages as a continuous integration tool. It is easy to use. Developers can get start on Snap in four steps.
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.
It supports several popular programming languages with different versions and different build tools. It integrates closely with GitHub. Different independent pipelines can do tests separately. Developers can choose either automatic tests or manual tests, depending on specific situations. Snap also allows deploying a web page from a command-line command. It offers developers more flexible space to do different kinds of tests.
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>
=='''References'''==
 
<div id="referencesAnchor"></div>
==== Deployment====
[1] Continuous integration. (Written February 5, 2015). In Wikipedia, The Free Encyclopedia. Retrieved February 9, 2015, from http://en.wikipedia.org/wiki/Continuous_integration
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:
 
[[File:Snap_ci_manual_stage.jpg‎ |frame|center|Stage Info]]
 
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 [http://docs.snap-ci.com/working-with-branches/automatic-branch-tracking/ Automatic Branch Tracking] and [http://docs.snap-ci.com/working-with-branches/integration-pipelines/ 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:
 
[[File:Snap_ci_auto_branch_tracking.jpg |frame|center|Different Branches‎]]
 
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:
 
[[File:Snap_ci_stage_history.jpg |frame|center|Stage History‎]]
 
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'''==
 
 
=='''GitHub Integration'''==
 
Snap CI integrates closely with [https://github.com/ GitHub].  It in fact does not support any other version control system.  GitHub is of course very popular for both open-source and closed-source software projects in many programming languages.  So, Snap CI focusing its efforts on GitHub makes sense for anyone using GitHub.
 
Snap CI by default triggers a build whenever a push is made to the user's GitHub repository, including any Git branch.  When a commit is made to a branch, it can also attempt to merge the branch with the master branch, and report the results.
 
Snap CI also tracks pull requests.  It runs a build to show what the result would be if the pull is merged.
 
An email is sent to developers whenever a build fails.
 
 
 
=='''Programming Language Support'''==
 
Snap CI supports [https://docs.snap-ci.com/the-ci-environment/languages/ many programming languages] and automated build systems for them.  For Java, for instance, it supports Java 6, 7, and 8, and, for build tools, Maven and Ant.  For Ruby, it supports bundler and rake.
 
It can automatically detect which build tools are used in the project, for certain build tools.  For instance, if a pom.xml file is present in a Java project, Snap CI can automatically configure itself for Maven.  (Apparently, the POM must be present in the top-level directory in the Git repository for Snap CI to detect it automatically.  If the Java project is in a lower-level directory, it is still possible to configure Snap CI manually to support Maven.)
 
 
=='''Pipelines'''==
 
 
Snap CI allows a series of customized steps whenever it evaluates a build.  Each step in the pipeline is at the core a series of command-line commands on the Snap CI server.  There is an option to set custom environment variables.  The console output is shown for each step.  If a step fails, the pipeline will halt; the later steps will not execute.
 
Both automatic and manual steps are allowed.  One would normally want to run most of the tests automatically with each commit.  However, a step can also perform a release of the software, which normally one would only want to run manually, not with each Git commit. For instance, a step may deploy a web application to Heroku or Amazon Web Services.  It may also upload a software release file in its final form to a web site for distribution, such as to SourceForge or the project's GitHub releases page.
 
 
=='''Limitations'''==
 
The only output from tests that Snap CI provides are output to the console or to files.  There is no way to see the test results in the Snap CI GUI.  Some other continuous integration tools provide web pages for viewing specific forms of tests.  For instance, in [http://jenkins-ci.org/ Jenkins CI], one can see whether individual JUnit tests pass, or view results from static analysis tools like CheckStyle or PMD, for which Jenkins has specialized plugins.


Snap CI certainly does allow deploying a web page from a command-line command.  So, it is not necessarily a great limitation that it does not have a specialized GUI for tests if one has means of generating web pages with test results.  Some build tools, such as Maven, can produce web pages with test output without much effort (such as by adding a few lines in the XML configuration file).
[2] Why Snap-(CI) and Travis-(CI) are not the same thing.  (Written July 22, 2014).  Retrieved February 9, 2015, from http://blog.snap-ci.com/blog/2014/07/22/why-snapci-and-travisci-are-not-the-same-thing/


[3] Comparison of continuous integration software. (Written January 27, 2015). In Wikipedia, The Free Encyclopedia. Retrieved February 9, 2015, from http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software


 
[4] What are the best hosted continuous integration (CI) services?  (Written January 28, 2015).  Retrieved February 14, 2015, from http://www.slant.co/topics/186/~what-are-the-best-hosted-continuous-integration-ci-services
=='''Conclusion'''==
 
=='''References'''==
<references/>

Latest revision as of 11:45, 15 February 2015

Snap Continuous Integration

Snap Continuous Integration (Snap CI) is a hosted continuous integration and continuous delivery service.

Background on Continuous Integration

Continuous integration (CI) is a software engineering practice that facilitates collaborative software development. It is the practice of continuously evaluating how different developers' work would integrate, such as by running tests and performing builds several times per day. It is often associated with extreme programming (XP), but it can also be used with other approaches to software development.

CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. 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. [1]

In CI, developers commit their code to a build server, which automatically runs tests either periodically or after every commit, and reports the results to the developers via email or other methods. CI quality control has to be different from the traditional quality control processes of unit, system, and system integration testing.

In addition to running the unit and integration tests, CI servers will 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. [1]

Examples

Example 1: Getting started on Snap CI

Snap CI is free to use for open source projects; for pricing for private projects, see here. It is easy to register your software project with Snap if your project is on GitHub. Snap's web site provides simple directions, which in summary are as follows:

Sign in

To sign up with Snap, visit Snap CI and click 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 to access your repositories, which it requires in order to function. Snap's web site says that "We never, ever commit code to your repository or look at your source code."

Snap CI website

Add your repository

Once you are signed in, Snap will present a list of all the public repositories on GitHub to which you have access. If you are an administrator on any of those repositories, you can build that repository on Snap.

Your repository list


Configure your build

When you select a repository to build on Snap, you can choose languages, databases, artifacts, secure files, dependency managers, and other conventions that may indicate how your build could be set up. If you use an automated build tool for your software, this step may be straightforward, but otherwise it might require some effort.

Configure your build

Build

After completing the steps above, all that is left to do is click "Build now" and let Snap run your build.

Build passed

Example 2: Heroku Deployment with Snap CI

When you want to deploy applications on Heroku, you can easily make Snap test and deploy your applications. This section shows how to do so with a Ruby on Rails project. The steps are as follows:

Snap CI configuration

Heroku currently requires your production database to be PostgreSQL. In Snap, you need to specify that you are using PostgreSQL.
Once you have Snap connected to your GitHub repository, you can click "ADD STAGE" to add a new stage named "DEPLOY".
After that, you can choose a deploy tool, such as "Heroku (basic)".

Snap CI Configuration

Set Heroku credentials

When you click "Heroku Credentials", you can login to Heroku. Then Heroku will ask you whether you want to authorize or not. Click "Allow", if you want to authorize, and you will see your Heroku account shown on the Snap website, just like in the last picture in circle number 4.

Set Heroku credentials

Save and Run

Then click the "Save" button at the upper-right corner of the Snap web page. Snap will automatically run, and you can check whether your application passes.

Passed

Programming Language Support

Snap supports many programming languages and automated build systems for them. For Java, for instance, it supports Java 6, 7, and 8, and, for build tools, Maven and Ant. For Ruby, it supports bundler and rake.

It can automatically detect which build tools are used in the project, for certain build tools. For instance, if a pom.xml file is present in a Java project, Snap CI can automatically configure itself for Maven. (Apparently, the POM must be present in the top-level directory in the Git repository for Snap CI to detect it automatically. If the Java project is in a lower-level directory, it is still possible to configure Snap manually to support Maven.)


GitHub Integration

Snap integrates closely with GitHub. GitHub is of course very popular for both open-source and closed-source software projects in many programming languages. So, Snap focusing its efforts on GitHub makes sense for anyone using GitHub.

Snap by default triggers a build whenever a push is made to the user's GitHub repository, including any Git branch. When a commit is made to a branch, it can also attempt to merge the branch with the master branch, and report the results.

Snap also tracks pull requests. It runs a build to show what the result would be if the pull is merged.

An email is sent to developers whenever a build fails.

Pipelines

Snap allows a series of customized steps whenever it evaluates a build. The steps together are called a "pipeline". They can report different test information (pass or fail, the specific fail position) about your repository. What is more, you can even assign deployment of the software to testing or production environments, and the execution of either automatic or manual tests against these deployed environments.

Many continuous integration tools have the feature of building the software and running tests when a change happens. However, Snap augments this feature with the ideas of "deployment pipelines" and "continuous delivery". Snap can in this manner perform more steps than other tools. 

 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 easily packaged at any time. Have a rigorous set of automated tests and robust deployment scripts and tools.

Each step in the pipeline is at the core a series of command-line commands on the Snap server. The console output is shown for each step. If a step fails, the pipeline will halt; the later steps will not execute.

Both automatic and manual steps are allowed. One would normally want to run most of the tests automatically with each Git commit, and perhaps deploy the software to a test environment. However, a step can also perform a release of the software, which normally one would only want to run manually, not with each commit. For instance, a step may deploy a web application to Heroku or Amazon Web Services. It may also upload a software release file in its final form to a web site for distribution, such as to SourceForge or the project's GitHub releases page. The final "publish" stage will not be executed unless someone manually triggers it. It means any changes made to the project will not be put into the production version automatically, which reduces the risks.

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.[2]

Support for Multiple Branches

Snap supports having different pipelines for different Git branches. Each branch may thus be tested separately.

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. ... 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. [2]

Different Branches[2]‎

Comparison with Other Continuous Integration Tools

There are more than 30 continuous integration tools designed to adapt to different platforms. Here are several tools that can connect to Github and build Ruby projects.

Comparison of Continuous Integration Tools [3]
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 E-mail 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 E-mail 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 GitHub, Heroku, 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 E-Mail 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 does have some limitations compared to other CI tools. Notably, the only output from tests that Snap provides are output to the console or to files. There is no way to see the test results in the Snap GUI. Some other continuous integration tools provide web pages for viewing specific forms of tests. For instance, in Jenkins CI, one can see whether individual JUnit tests pass, or view results from static analysis tools like CheckStyle or PMD, for which Jenkins has specialized plugins.

Snap certainly does allow deploying a web page from a command-line command. So, it is not necessarily a great limitation that it does not have a specialized GUI for tests if one has means of generating web pages with test results. Some build tools, such as Maven, can produce web pages with test output without much effort (such as by adding a few lines in the XML configuration file).

The website [4] lets users vote on the best hosted continuous integration services. Although Snap CI does not get the highest votes, the web site still lists many advantages for it, such as:

1.Build artifact promotion and propagation

2.Ability to deploy to multiple environments
3.Manually triggered promotions from one environment to another

4.Track pipeline stage history

Conclusion

Snap CI has many advantages as a continuous integration tool. It is easy to use. Developers can get start on Snap in four steps. It supports several popular programming languages with different versions and different build tools. It integrates closely with GitHub. Different independent pipelines can do tests separately. Developers can choose either automatic tests or manual tests, depending on specific situations. Snap also allows deploying a web page from a command-line command. It offers developers more flexible space to do different kinds of tests.

References

[1] Continuous integration. (Written February 5, 2015). In Wikipedia, The Free Encyclopedia. Retrieved February 9, 2015, from http://en.wikipedia.org/wiki/Continuous_integration

[2] Why Snap-(CI) and Travis-(CI) are not the same thing. (Written July 22, 2014). Retrieved February 9, 2015, from http://blog.snap-ci.com/blog/2014/07/22/why-snapci-and-travisci-are-not-the-same-thing/

[3] Comparison of continuous integration software. (Written January 27, 2015). In Wikipedia, The Free Encyclopedia. Retrieved February 9, 2015, from http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software

[4] What are the best hosted continuous integration (CI) services? (Written January 28, 2015). Retrieved February 14, 2015, from http://www.slant.co/topics/186/~what-are-the-best-hosted-continuous-integration-ci-services

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2015/ch1a_6_TZ&oldid=93780"