Continuous Integration

http://electric-cloud.com/lp/electricflow-devops-platform/
https://blog.snap-ci.com/blog/2015/06/22/continuous-deployment-strategies/
http://www.sitepoint.com/deploying-php-apps-digitalocean-dploy-io
http://inedo.com/buildmaster
https://www.codeship.io/
https://codeship.com/features/parallelci
http://www.sitepoint.com/sailing-parallel-seas-codeship/
http://www.sitepoint.com/continuous-delivery-right-way-deploy-software
http://www.sitepoint.com/set-continuous-deployment-ninefold/
https://travis-ci.org/
http://www.sitepoint.com/quick-tip-what-is-gradle-and-how-does-it-work-with-android-studio/

Continous Integration is a software development practice where members of a team integrate their work frequently, usually at least daily, leading to multiple integration per day. Each integration is verified by an automated build (including tests) to detect integration errors as quickly as possible.

Everything you need to do a build should be in the repository, including test scripts, property files, database schema, install script, and third party libraries. You must put everything required for a build into source control system, however you may also put other stuff that people generally work with in there too. IDE configuration are good to put in there because that way it is easy for people to share the same IDE setups.

In general, you should store in source control everything you need to do a build, but nothing that you actually build. Some people keep the built products in source control, but I consider that to be a smell - an indication of a deeper problem, usually an inability to reliably recreate builds.

One of the features of version control systems is that they allow you to create multiple branches to handle different streams of development, but it's frequently overused and gets people into trouble. Keep your use of branches to a minimum. (Reasonable branches are bug fixes of prior production releases and temporary experiments).

Tools for automated builds: Unix has make. Java has Ant. .NET has Nant and MSBuild. Make sure you can build and launch your system using a single command.

A common mistake is not to include everything in the automated build. The build should include getting the database schema out of the repository and firing it up in the execution environment. Anyone should be able to bring in a virgin machine, checkout the sources out of the repository, issue a single command, and have a running system on their machine.

CruiseControl
Atlassian Bamboo
TeamCity
Pulse
Apache Hudson
https://www.codeship.io/

http://www.linux.com/feature/60657

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License