=='''Compare Different Continuous Intergration Tools'''==
=='''Functionality'''==
Snap allows a series of customized steps whenever it evaluates a build. 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 a "Deployment Pipeline" 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 CI 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.
<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.<ref>http://blog.snap-ci.com/blog/2014/07/22/why-snapci-and-travisci-are-not-the-same-thing/</ref></blockquote>
The final "publish" stage will not be executed unless someone manually triggers it. It means any changes made into the project will not put into the production version automatically, which reduce the risks. And you can assign any stages to become manually triggered, which increase the flexbility of Snap CI.
=='''Comparison with Other Continuous Integration Tools'''==
=== Common Continguous Intergration Tools ===
=== Common Continguous Intergration Tools ===
Line 265:
Line 290:
=='''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.
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. <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.
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.<ref>http://en.wikipedia.org/wiki/Continuous_integration</ref>
Getting started on Snap CI
It is easy to register your software project with Snap CI 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 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 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.
Configure your build
Build
After completing the short steps above, all that is left to do is click "Build now" and let Snap run your build.
Build passed
Programming Language Support
Snap CI 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 CI manually to support Maven.)
GitHub Integration
Snap CI integrates closely with 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.
Functionality
Snap allows a series of customized steps whenever it evaluates a build. 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 a "Deployment Pipeline" 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 CI 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.
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.<ref>http://blog.snap-ci.com/blog/2014/07/22/why-snapci-and-travisci-are-not-the-same-thing/</ref>
The final "publish" stage will not be executed unless someone manually triggers it. It means any changes made into the project will not put into the production version automatically, which reduce the risks. And you can assign any stages to become manually triggered, which increase the flexbility of Snap CI.
Comparison with Other Continuous Integration 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 so many Continuous Intergration tools. Snap CI has its own distinctive advantages.
1. 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 Deployment Pipeline and Continuous Delivery. What this means is Snap CI will do 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.
2. Stages Deployment Options
Stages in Snap are a set of logically related commands. They can tell you 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 environments and the execution of either automatic or manual tests against these deployed testing environments.
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.<ref>http://blog.snap-ci.com/blog/2014/07/22/why-snapci-and-travisci-are-not-the-same-thing/</ref>
One more thing, the final “publish”stage will not be executes unless someone manually triggers it. It means any changes made into the project will not put into the production version automatically, which reduce the risks. And you can assign any stages to become manually triggered, which increase the flexbility of Snap CI.
3. Artifacts
After executing each stage, you can ask Snap CI to save some files and directories in your build as an artifact directory, such as packages, binaries. Snap CI will then save and restore the contents of this directory for each stage, which will apparantly shrink test time.
4. Different Branches and Pipelines
Snap CI supports defferent banches and different commits of same branch to build their own pipeline and test separately.
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.
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 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).
