Continuous X
E N D
Presentation Transcript
Continuous X X in [Integration, Delivery, Deployment]
Continuous Integration • Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. • http://www.thoughtworks.com/continuous-integration • http://martinfowler.com/articles/continuousIntegration.html
Continuous Integration Practices • Maintain a single source repository • Automate the build • Make your build self-testing • Every commit should build on an integration machine • Keep the build fast • Test in a clone of the production environment • Make it easy for anyone to get the latest executable • Everyone can see what’s happening • Automate deployment
Continuous Integration – How • Developers check out code into their private workspaces. • When done, the commit changes to the repository. • The CI server monitors the repository and checks out changes when they occur. • The CI server builds the system and runs unit and integration tests. • The CI server releases deployable artefacts for testing. • The CI server assigns a build label to the version of the code it just built. • The CI server informs the team of the successful build. • If the build or tests fail, the CI server alerts the team. • The team fix the issue at the earliest opportunity. • Continue to continually integrate and test throughout the project.
ContinuousIntegration – TeamResponsibilities • Check in frequently • Don’t check in broken code • Don’t check in untested code • Don’t check in when the build is broken • Don’t go home after checking in until the system builds
Continuous Delivery • Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. • Continuous Delivery is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button.
Continuous Delivery Practices • Your software is deployable throughout its lifecycle • Your team prioritizes keeping the software deployable over working on new features • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them • You can perform push-button deployments of any version of the software to any environment on demand
Continuous Deployment • Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests. • Essentially, “it is the practice of releasing every good build to users,” explains Jez Humble, author of Continuous Delivery.
The story • Alex has just written a refactoring of some website backend code. Since it was a small task, it's committed and Alex moves on to the next feature. • When the code is deployed in production two weeks later it causes the entire site to go down. A one-character typo which was missed by automated tests caused a failure cascade reminiscent of the bad-old-days at twitter. It takes eight hours of downtime to isolate the problem, produce a one character fix, deploy it and bring production back up. • Alex curses luck, blames human infallibility, inevitable cost of software engineering and moves on to the next task. • http://timothyfitz.com/2009/02/08/continuous-deployment/
ContinuousDeploymentAnti-patterns • More manual testing • More up-front planning • More automated testing • Code reviews and pairing • Ship more infrequently
ContinuousDeliveryvs.ContinuousDeployment • Continuousdeployment =>Continuous delivery • Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. • Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle – that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes. • http://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/
What is it • Go is an advanced Continuous Integration and Release Management system. • Go lets you distribute your builds across many computers -- think 'build grid' or 'build cloud': • Run your tests on several different platforms to make sure your software works on all of them • Split your tests into several parallel suites and run them at the same time to get results faster • Manage all your environments centrally so you can promote builds from one environment to the next • http://www.thoughtworks.com/products/docs/go/13.4/help/concepts_in_go.html
Agent lifecycle • A grid of Agents can run Jobs. Agents periodically contact the Go server to ask if there is any work, and get assigned Jobs if have sufficient resources • When an Agent runs a Job, it creates a sandbox directory under the agent's directory • For example consider a pipeline named "pipelines/my-pipeline". On a default linux install this would be "/var/lib/go-agent/pipelines/my-pipeline". On a default Windows installation it would be "C:\Program files\Go Agent\pipelines\my-pipeline". • All materials are updated in this directory • For example suppose the pipeline has an SVN material with a destination folder name of "tools" then the svn files will be checked out into that "tools" directory. When you have multiple materials specified, you must specify a "dest" for each material.
Agent lifecycle (2) • Once the materials have all been updated, the Agent runs each of the tasks in turn (the task runs relative to the pipeline sandbox) • For example if there is a task that runs "/usr/bin/make" with a workingdir of "tools/my-tool" then this will run in the directory "pipelines/my-pipeline/tools/my-tool". • When all the tasks have been completed the agent will publish any artifacts defined in the Job
Pipeline • A job is a set of build tasks that can be performed on a single agent in a cloud • Jobs are grouped into stages. A stage is a collection of build jobs that can be executed in parallel. • This is the mechanism that allows you to, for example, split test suites into multiple parallel streams or run the same build on multiple platforms simultaneously. A stage passes only when all the jobs in the stage pass.
Pipeline (2) • Stages are then joined sequentially into a pipeline. Stages trigger in the order they appear in the pipeline's raw configuration. • They can be triggered by: • a change in your version control system, • manually forcing the pipeline to become active or • by a dependency on a given stage of another pipeline. • When a stage completes successfully, it triggers the next stage in the pipeline automatically or after manual approval
Deployment and Environments • In Go, deployment is simplified down to a single click • An environment in Go is essentially a collection of agents and pipelines • An environment pipeline is used to perform tasks specific to an environment • Each of these environment pipelines deploys using the same build • The environments dashboard give you a view of which versions are deployed in which environment
Reklama:GetIdeaswithGoThoughtworks • http://www.thoughtworks.com/products/go-continuous-delivery/resources#Webinars
