Download - Smart development environments
Smart development
environmentS
Szczyrk 27.10.2013
Wojciech Sznapka
PHPCon Pl
Cześć!:)
Hanys ze Ślůnska wito Wos
pierońsko piyknie
Since 2006 regularly in a teams of developers
Loves software craftsmanship,
sophisticated architectures, Big Data and automation
Why a development environment needS care?
Because mess frustrates people
And repetitions leads to routine and are always
error prone
Automation is always better than written process
the verSion control
GitHub private repositories
Every team member has his own fork
He creates a feature branch related to the User Story from
Jira, he is working on
He works on his own machine
After a series of commits to his feature branch he opens
a pull request
Other devs review the code
and make comments
pro tip: smaller pull request are easier to review
and maintain
Developer fixes things and pushes again
The responsible person merges pull request into
develop branch
the code metricS
Most of new projects are started based on Symfony
XSolve Edition
It contains standard build.xml for Ant
There are around 28 targets
Most important are:
Most important are: » build - used to deploy
Most important are: » build - used to deploy
» ci - run on Jenkins
Most important are: » build — used to deploy
» ci — run on Jenkins
» cli — runs code sniffer, mess detector, copy paste detector on ClI to check curremt
status before committing
Most important are: » build — used to deploy
» ci — run on Jenkins
» cli — runs code sniffer, mess detector, copy paste detector on ClI to check curremt
status before committing
» thresholds-check — to build PRs
Code metrics are collected by Jenkins
and available there
BuildS
We build every change in develop branch
Also we build every project in the morning to see
if passing time hasn’t affected the code :-)
The third build goes for Pull Requests
We’ve integrated Jenkins GitHub PR Builder
It runs tests and checks if code metrics
warnings don’t exceed thresholds
This mechanisms helps us to not watch for code style
or obvious things during code reviews, but to focus on
what’s important
deploymentS
A standard servers structure:
A standard servers structure: » development
A standard servers structure: » development
» ci server
A standard servers structure: » development
» ci server
» test server
A standard servers structure: » development
» ci server
» test server
» stagagging (a.k.a. preview) server
A standard servers structure: » development
» ci server
» test server
» stagagging (a.k.a. preview) server
» production
We use launcher to update application on test
and stagging server
launcher is our Silex based application that
launches ant tasks, triggered by github hook
it updates test env for every change...
... and staging for every new tag
communication
We use hipchat
it has a great and simple api
and plenty of tools has built-in integration
and plenty of tools has built-in integration
» Github
and plenty of tools has built-in integration
» Github
» jira
and plenty of tools has built-in integration
» Github
» jira
» jenkins
and plenty of tools has built-in integration
» Github
» jira
» jenkins
» new relic
and plenty of tools has built-in integration
» Github
» jira
» jenkins
» new relic
» zabbix
also our internal tools uses hipchat api to notify
important facts
of course we have github, jira, jenkins emails
notifications
extraS
Github-metrics
it counts pull requests and commits per developer
across all repos and pushes it to hipchat every morning
at 10:00
xSolve developers metrics
harvesters jenkins api to get number of violations
(or fixes) for every developer
Summary
it requires a lot of effort to put all those tools
together
even more work is required to maintain and keeps it
running
But after some time it works gloriously
teams don’t waste time on non-programming
work
it’s way easier to introduce new team
members
and you have a lot more time to think about solving world’s problems
thank you
Dołącz do nas!
