Continuous Delivery By Uchit Vyas [email protected] www.attuneuniversity.com Table of Content I. Getting started II. Version Controlling with Git III. Git with Eclipse (EGit) IV. Eclipse SSH Configuration V. Installing Jenkins VI. Installing Ruby with RVM VII. Creating a job in Jenkins VIII. Configuring the Tools Continuous Delivery 1 About Author Uchit Vyas a B.Tech. Graduate in Computer Science with a research interest in ESB & Cloud and is a certified by Cisco (CCNA), VMware (VSP) and Red Hat Linux (RHCE) professional. He has an energetic strength to work on multiple platforms at a time and ability to integrate open source technologies. He works as a Sr. Consultant and looking afterAWS – Cloud, Mule ESB, Alfresco, Liferay and deploying Portal, ECM system. He was previously working with TCS as Assistant System Engineer. Over 3+ years of hands on experience on Open Source technologies, he manages to guide the team and deliver the projects and trainings. He has provided 13+ trainings on Cloud Computing, Continuous Delivery, Alfresco and Liferay in couple of months. During past years he moved over 80% of Attune Infocom business processes to the Cloud with implementing agile SDLC methodology on Amazon, Rackspace and private clouds like Eucalyptus, Openstack. His skills are not limited as his designing and managing Cloud environment/infrastructure, server architecture. He is also active in shell scripting, auto deployment, supporting hundreds of Linux and Windows physical & virtual servers hosting databases, and applications with Continuous delivery using Jenkins / Cruise Control with Puppet / Chef scripting. 2 Continuous Delivery Getting started Continuous Delivery (CD) is a pattern language used in software development to automate and improve the process of software delivery. Techniques such as automated testing, continuous integration and continuous deployment allow software to be developed to a high standard and easily packaged and deployed to test environments, resulting in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead. The technique was one of the assumptions of extreme programming but at an enterprise level has developed into a discipline of its own, with job descriptions for roles such as "buildmaster" calling for CD skills as mandatory. Figure 1 : Continuous Delivery Pattern Continuous delivery treats the commonplace notion of a deployment pipeline as a set of validations through which a piece of software must pass Continuous Delivery 3 on its way to release. Code is compiled if necessary and then packaged by a build server every time a change is committed to a source control repository, then tested by a number of different techniques (possibly including manual testing) before it can be marked as releasable. Figure 2 : Architecture for Continuous Delivery Developers use to a long cycle time may need to change their mindset when working in a CD environment. It is important to understand that any code commit may be released to customers at any point. Patterns such as feature toggles can be very useful for committing code early which is not yet ready for use by end users. Other useful techniques for developing code in isolation such as code branching are not obsolete in a CD world, but must be adapted to fit the principles of CD - for example, running multiple long-lived code branches can prove impractical, as a releasable artifact must be built early in the CD process from a single code branch if it is to pass through all phases of the pipeline. 4 Continuous Delivery Continuous Delivery Tools List I usually shy away from giving a list of tools that we use because people have their particular tool preferences and are sometimes indignant in considering others. However, I realize it's helpful for people to understand the tool landscape when it comes to Continuous Delivery in the Cloud just so they know where to start looking. After reading my Continuous Integration book, this is often the most common question I get from readers. I want to say up front that I'm not advocating the use of any of these tools, just that we've used some of the tools or investigated when creating Continuous Delivery systems. I'm sure some of the tools that we use on a daily basis won't make it to this list. The precise toolset a team may choose to use depends upon numerous factors including project, cost and customer constraints – to name a few. Therefore, I suggest that you focus more on the type of tool and determine which one meets their particular needs for their Continuous Delivery ecosystem. Just because I'm not mentioning a particular tool doesn't mean I'm not using it or that I don't think it's a good tool; these are meant to be illustrative. We tend to focus more on freely-available tools because people can download and use them quickly. There are good reasons to choose commercial tools. As implied before, you don't need to be using all of these tools to get significant benefit from Continuous Delivery. Start small and build it up. I've listed some of the tools in each category for the Java, .NET and Ruby platforms. Since, we lean heavily toward Cloud tools; you'll see that we opt for the SaaS-based tools, when applicable. Let me know if your Continuous Delivery 5 preferred tool didn't make the list. Ok, there's my disclaimer. On with the list: Application Containers – JBoss, Tomcat, IIS, Mongrel. NOTE: there are so many app containers; I'm not going to try to list all of them. Build Tools – Ant, AntContrib, NAnt, MSBuild, Buildr, Gant, Gradle, make, Maven, Rak e Code Review - Crucible Code Insight – Fisheye Continuous Integration – Bamboo, Jenkins, AntHill Pro, Go, TeamCity, TFS 2010 Cloud IaaS - AWS EC2, AWS S3 , Windows Azure Cloud PaaS – Google App Engine, AWS Elastic Beanstalk, Heroku Database – Hibernate, MySQL, Liquibase, Oracle, PostgreSQL, SQL Server, SimpleDB, SQL Azure, Ant, MongoDB Database Change Management – dbdeploy, Liquibase Data Center Configuration Automation – Capistrano, Cobbler, BMC Bladelogic, CFEngine, IBM Tivoli Provisioning Manager, Puppet, Chef, Bcfg2, AWS Cloud Formation, Windows Azure AppFabric NOTE: There are many names and overlap for this tool "category". Dependency Management – Ivy, Archiva, Nexus, Artifactory, Bundler Deployment Automation – Java Secure Channel, ControlTier, Altiris, Capistrano, Fabric, Func Information Sharing – Confluence, Google Apps Installer – InstallShield, IzPack Integrated Development Environment (IDE) – Eclipse, IDEA, Visual Studio 6 Continuous Delivery Issue Tracking - Greenhopper, JIRA Multi-Type – rPath Passwords – PassPack, PasswordSafe Protected Configuration – ESCAPE, ConfigGen Project Management – JIRA, Pivotal Tracker, SmartSheet Provisioning - JEOS, BoxGrinder, CLIP, Eucalyptus, AppLogic Reporting/Documentation – Doxygen, Grand, GraphViz, JavaDoc, NDoc, SchemaSpy, UmlGraph Static Analysis - CheckStyle, Clover, Cobertura, FindBugs, FxCop, JavaNCSS, JDepend, P MD, Sonar, Simian Systems Monitoring – CloudKick, Nagios, Zabbix, Zenoss Testing – AntUnit, Cucumber, DbUnit, webrat, easyb, Fitnesse, JMeter, JUnit, NBeh ave, SoapUI, Selenium, RSpec,SauceLabs Version-Control System – SVN/Subversion, git, Perforce Continuous Delivery 7 Version Controlling with Git There are many options for version control, but the Rails community has largely standardized on Git, a distributed version control system originally developed by Linus Torvalds to host the Linux kernel. Git is a large subject, and we‘ll only be scratching the surface in this book, but there are many good free resources online; I especially recommend Pro Git by Scott Chacon (Apress, 2009). Putting your source code under version control with Git is strongly recommended, not only because it‘s nearly a universal practice in the Rails world, but also because it will allow you to share your code more easily and deploy your application right here in the first chapter. Installing Git Let‘s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform. Installing from Source If you can, it‘s generally useful to install Git from source, because you‘ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you‘re on a very up-to-date distro or are using backports, installing from source may be the best bet. To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you‘re on a system 8 Continuous Delivery that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site: http://git-scm.com/download Then, compile and install: $ tar -zxf git-1.7.2.2.tar.gz $ cd git-1.7.2.2 $ make prefix=/usr/local all $ sudo make prefix=/usr/local install After this is done, you can also get Git via Git itself for updates: $ git clone git://git.kernel.org/pub/scm/git/git.git First-time system setup After installing Git, you should perform a set of one-time setup steps. These are system setups, meaning you only have to do them once per computer: $ git config --global user.name "Your Name" $ git config --global user.email [email protected] Continuous Delivery 9 I also like to use co in place of the more verbose checkout command, which we can arrange as follows: $ git config --global alias.co checkout This tutorial will usually use the full checkout command, which works for systems that don‘t haveco configured, but in real life I nearly always use git co.