1. X in [Integration, Delivery, Deployment]
Continuous X
X in [Integration, Delivery, Deployment]

2. 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.

3. 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

4. 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.

5. Continuous Integration – Team Responsibilities
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

6. 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.

7. 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

8. 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.

9. 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.

10. Continuous Deployment Anti-patterns
More manual testing
More up-front planning
More automated testing
Code reviews and pairing
Ship more infrequently

11. Continuous Delivery vs. Continuous Deployment
Continuous deployment => 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.

13. Įrankiai Thoughtworks Go

14. 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

15. 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.

16. 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

17. 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.

18. 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

19. Pipeline (3)

20. Pipeline dependencies

21. 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

22. Deployment and Environments (2)

23. Value Stream Map

24. Reklama: Get Ideas with Go Thoughtworks