This is introduction to GOCD, CI CD tool from thoughtspot

2. Practice in software engineering, of merging all developer working copies with a shared mainline several times a day.
The main aim of CI is to prevent integration problems (merge hell or integration hell).
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. Producing production
ready package continuously, with minimal or no manual intervention.
Continuous deployment is the next step of continuous delivery, Every change that passes the automated tests is deployed to production
automatically.

3. • Thought Works released kind of first Continuous Integration Server named “Cruise Control” as a free
software.
• Later in July 2008 release Continuous Delivery Product called “Cruise”
• Later “Cruise” renamed as “GO”
• Earlier in 2014 Though Works made “GO” Open Source [www.go.cd]
• How it works: Go Server and Agents
• Pipelines
• Go pipelines offer workflows flexibility.
• It also offers 4 Levels of abstractions
• Value Stream Map
• To visualizes your entire continuous delivery workflow. With a single glance you can trace a change
from commit all the way to deployment.
• Go Vs Jenkins (Most popular CI tool)

4. • Go Server
• User Management, Server configuration, Artifact repository, Package
repository etc., all managed at server.
•
• One or many Go Agents (Agents reach out to GO Server at startup)
• Agents can run on any machine
• Agents are workers, they execute the task assigned by server.

5. • Agents periodically contact the Go server to ask if there is any work.
• The server checks to see what resources the Agent has, and assigns any available Jobs that
match those resources.
• Categorize Agents By
Environment 1 Environment 2
Environment 3
Agent1 Agent..n
Agent1
Agent..n

6. Pipeline is a set of validations through which a piece of software must pass on its
way to release
• Every Commit can not be released, but its a release candidate
• If it passes all the steps listed in deployment pipeline then it can be released

8. Stages
• Stages run consecutively
• Each stage triggered automatically by
successful completion of previous stage.
• Can also be triggered manually.
• Stage can also wait to get triggered manually.
git commit triggers
Pipeline
Stage: Build
Jobs
• Stages run concurrently with a stage
• Job fail it will fail stage it is in.
• Job can run in parallel over multiple agents.
Task
• Task run consecutively with a job
• These are actual commands or scripts
• Example ant, maven, fetch artifact,
script or shell command
Approval
• This can be automatic or manual.
• Automatic on last Stage success or manual for
manual intervention .
 Pipeline can have multiple Stages (run consecutively)
 Stages can have multiple Jobs (runs concurrently)
 Jobs can have multiple task (run consecutively)
Stage: Deploy Stage: Test
Pipeline: WebAppA
Job: Deploy DB
Job: Deploy Conf
Job: Deploy Web App

10. • Pipeline 1 depends on an SCM.
• Pipeline 1 will trigger each time it polls the SCM and detects a new revision.
• Pipeline 1 and 2 depend on the same SCM.
• A new revision will trigger both Pipeline 1 and 2.
• Pipelines 1 and 2 depend on an SCM.
• Pipeline 3 depends on Pipelines 1 and 2.
• Imp: Pipeline 3 will only trigger if a new revision (SCM) has successfully passed through
both Pipeline 1 and Pipeline 2

11. • Pipelines 1 and 2 depend on SCM 1.
• Pipeline 3 depends on Pipelines 1 and 2, and SCM 2.
• Pipeline 3 will trigger:
•if a new revision (SCM 1) has successfully passed through both
Pipeline 1 and Pipeline 2
•each time it polls SCM 2 and detects a new revision
• Pipelines 1 and 2 depend on SCM 1.
• Pipeline 3 depends on SCM 2.
• Pipeline 4 depends on Pipelines 1, 2 and 3.
• Pipeline 4 will trigger:
• if a new revision (SCM 1) has successfully passed through
Pipelines 1 and 2.
• each time Pipeline 3 successfully completes (SCM 2)

13. A value stream map can be generated for every execution. It provides you with the ability to:
• See what caused the current pipeline to be triggered.
• See what downstream pipelines were triggered by the current pipeline.
• See the status of the current pipeline and all its upstream and downstream dependencies.
• See changes in dependencies of the pipeline across different runs of it.
• Along with all this, it also allows you to easily debug problems when a dependency/configuration change
caused your build-test-release setup to break.

14. PROS:
• Visualization with Value Steam Map
• Fan in support - reduce risk of incompatible builds
• Powerful abstractions and their relationship:
Tasks inside Jobs inside Stages inside Pipelines
• Parallelizability
(jobs across agents, resources to tie jobs to a set of
agents)
• Security - Go can be configured (you can set https-only)
Cons
• Only a couple of extension points (plugins).
• Go Server is only one server no multiple server.
• Comes only with Jetty
PROS Compared to Cons of GO:
• Jenkins is easy to use "out-of-the-box"
• Hundreds of plugin available compare to few in GO
• Can be deployed to any web server.
• Can work with Master only with no agents, Go need
at least one agent.
• It works with VCS (plugins)
• Well-known, big user base, especially plugin writers.
Cons Compared Pros of GO:
• End-to-end visualization, not like GO VSM
• Fan in is hard to achieve.
• Jenkins authorization is per-user/group level
Go allows per-user/group and per-pipeline authorization

15. • Thoughtworks GO Products Docs
http://www.thoughtworks.com/products/docs/go/13.1/help/concepts_in_go.html
• Go Open Source Website
http://www.go.cd/
• Continuous Delivery.com
http://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley
Signature Series (Fowler)) http://amzn.com/0321601912