Continuous integration / deployment can be a daunting task. Especially if you are a team of one, or one among a small team. TeamCity is "continuous integration for everyone" It's a self hosted CI build server that is highly customizable for just about any project. I've built RocketFuel's CI/CD system on a spare box with TeamCity and customized it to handle legacy PHP applications and modern framework based projects. We'll cover install and configuration and all of the flexibility of setting up projects at that build, test, report errors, and trigger deployments for various application scenarios.

1. Continuous Integration
How I stopped guessing if that merge was bad
Joe Ferguson
https://joind.in/14016

2. Continuous Integration?
Continuous Deployment?

3. Continuous Integration
Frequently integrate code changes into the
existing code repository
Merging branches to master/production
Automated build tests to ensure issues found
quickly
Does not have to be deployed

4. Continuous Delivery
Produce valuable changes in code in short cycles
to be released at any time.
AKA: Continuous Deployment
Automated build tests to ensure issues found
quickly
Deployment happens on successful build

5. Continuous Integration
or
Continuous Delivery

6. Which is right for you?
Your goal should be Continuous Integration (at
least!)
Strive for Continuous Delivery if it makes sense
Applications with a live event component may
not be suited for Continuous Delivery

7. The Problem
2 Developers and now scaling up
No longer 1 developer == 1 project
Version control is the obvious answer
What happens if the team just learning version
control?

8. Story Time!

9. Our Problem
Scaling up meant more developers contributing
to same code bases
Previously 1 developer per codebase

10. Our Process
Master always deployable / not broken
Feature branching off master
Feature branches merged to dev/staging
dev/feature merged to master (release / deploy)

11. What we needed
Private build testing
Cheap or Free (had to prove value to
stakeholders / managers)
Customizable for some pretty uncommon things
(So we thought)

12. There are a lot of CI
solutions out there

13. Travis-CI.org
Great for OSS
Private projects require paid account
Not hosted on your infrastructure

14. Jenkins-CI.org
Self hosted (Bring your own hardware)
Great flexibility and support
Just didn't click for me

15. Great Atlassian integrations
Utilizes Amazon’s EC2 for build agents
Greater appeal if you’re already using Atlassian
and Amazon products
https://www.atlassian.com/software/bamboo

16. Fully Functional Free Version (Limited Configs &
Build Agents)
Enterprise option (unlimited configs, more build
agents)
Self hosted (Bring your own hardware)
Runs on Windows / OS X / Linux

17. Installation
You’ll need Java installed
Configure Database (or use internal TeamCity)
Just want to poke around a bit?
https://github.com/curzona/vagrant-teamcity
Create Admin Account

18. Ready to start building!

19. Create a new project

20. Create a VCS Root

21. Create a Build Config

22. Attach VCS to Config

23. Auto Detected Build
Steps

24. Add Build Steps

25. Step 1 Composer Install

26. Step 2 Run phpunit

27. 2 Steps to Build

28. Running our first build

29. Build Log

30. Detailed Output

31. Detailed Output

32. Successful Build!

33. Failed Build :(

34. When a build fails the
steps after will not run*
*sometimes you do want a step to run

35. What happened?

36. Oh, Class not found

37. Finding the breaking
change

38. Finding the broken rev

39. Revert Change

40. Build Passes

41. Questions so far?

42. Now for something
more complex…

43. Fork in the road…
Testing real things can be hard
Manually create these sites / databases
Docker
Vagrant

44. Build Test a Web App

45. Create Build Config

46. Add VCS Root

47. Quick Note
You can add VCS Roots before or after you create a build configuration.
In our first example we did it before, in this example we did it after.

48. Adding Build Steps

49. Run DB Migrations

50. Seed the Database

51. Run PhantomJS

52. Copy files to vhost

53. Run Codeception

54. Stop PhantomJS

55. Reset Database

56. Test Our Build

57. Verifying our Tests

58. Automate our builds

59. Other Triggers

60. Now we have automatic
VCS triggered built tests

61. What next?

62. Deployments can be a
build step away!

63. Deployment
https://github.com/laravel/envoy

64. Envoy Deployment
https://github.com/laravel/envoy

65. Anything you can script
can be a part of your build

66. Some CI pain points
You have to duplicate your production
environment within TeamCity / other CI service
Starting out there will be a lot of trial & error
Don’t forget to back up your CI server configs!

67. Payoff is better than
the pain
Quick feedback on commits
Confidence level of your merges is huge
Less time resolving conflicts
Automate your deployments
Advanced build notifications

68. Feedback!
https://joind.in/14016
Joe Ferguson
Twitter: @JoePFerguson
Email: joe@joeferguson.me
Freenode: joepferguson
Contact Info: