Hauptsächlich arbeite ich an Infrastruktur, komme aber an vielen Stellen mit Softwareentwicklung in Berührung. Jedes Entwicklungsteam benötigt Komponenten, auf die es sich verlassen können muss. Neben der Bereitstellung solcher Komponenten für verschiedene Entwicklergruppen auf der einen Seite greife ich auch auf Entwicklungs-Infrastruktur zurück, welche von mir und anderen bereitgestellt wird. Nach einer kurzen Einführung wie Entwicklung früher gehandhabt wurde, werde ich einen kurzen Einblick geben, wie das Monitoring Plugins Projekt seine aktuelle Softwareentwicklung strukturiert hat und einige Komponenten vorstellen, welche es wert sein könnten sich damit zu beschäftigen, um einem Entwicklungsteam möglicherweise wieder neuen Schwung zu verleihen.

1. SOFTWARE DEVELOPMENT SEEN
FROM A YOLO^WDEVOPS
Jan Wagner
waja@cyconet.org
http://log.c5t.org/about

2. TOOLS WE USED TO MANAGE
OUR SOFTWARE
vi
nano
kate
joe
eclipse
netbeans
cp
rsync
ftp

3. PROBLEMS WITH OUR (OLD)
TOOLS
no chronological revisions
multiple different versions (forks) in production
multiple different local versions
f00b4r.php
f00b4r_20040410.php
f00b4r_production.php
distributed via scp/rsync/ftp

4. WAY OUT?
Version Control System
tracks changes of files and folder
when = date of the commit
who = name of author
why = commit message

5. TOOLS WE USED TO MANAGE
OUR SOFTWARE
CVS
Subversion
RCS

6. CLIENT-SERVER VERSION
CONTROL SOFTWARE
One linear software repository
with all versions
Server down, no development

7. AND NOW?
How to fix some of those issues?

8. DISTRIBUTED VERSION
CONTROL (RECENTLY MOVES)
BitKeeper
Mercurial / HG
Bazaar
Git

9. DISTRIBUTED VERSION
CONTROL

10. DISTRIBUTED VERSION
CONTROL
Local development possible
committing, branching, tagging ...
working offline
Exchange of code with all participants possible - directly
M-P

11. MONITORING PLUGINS
Team Communication
Mailing Lists
For legacy reasons
Mail seems not much loved these days
Issues / Pull Requests
Fits developers workflow
IRC
Most usual
Realtime communication for peer coding, release work
and discussions

12. MONITORING PLUGINS
Usual branches
Development - master branch
Hotfixes - maint-X.Y branch
usual cherry-pick from master
Feature - no strict naming convention
Pull Requests from external contributors
Branches where developers are working on specific
problems

13. MONITORING PLUGINS
Special branches
Proposed Updates - pu branch
Coverity Tests - coverity/master branch

14. MONITORING PLUGINS
Milestones
For prioritizing work and problems, we are using Milestones
Issues and Pull Requests are targeted for Milestones

15. MONITORING PLUGINS
Code contributions
via Pull Requests
Work by developers
done in Feature branches
even those are reviewed by other members usually
through Pull Requests

16. MONITORING PLUGINS
Quality Assurance
We ship test cases for plugins and C library functions
make test runs those
Can we take further?
Yes we did!

17. MONITORING PLUGINS
Quality Assurance
Automation with Travis-CI
Compiling and running make test on every push (to
github)

18. MONITORING PLUGINS
Quality Assurance
Automation with Travis-CI
This happens also for Pull Requests
Can be observed directly in the PR

19. MONITORING PLUGINS
Quality Assurance
Reliability of (Travis-)CI
Only as good as coverage of make test
When depending on external infrastructure, this may vary
Depends on reliability of CI-infrastructure / build servers

20. MONITORING PLUGINS
Quality Assurance
Code Quality
Static code analysis performed by Coverity Scan
Merged master via cronjob once a week into
coverity/master, Travis triggers the Coverity Scan

21. MONITORING PLUGINS
Infrastruture
On the surface we massively rely on external resources
In fact we run own project infrastructure
Website
Git Mirror
Mailing Lists

22. GIT HOSTING SOLUTIONS
Gitlab
Gogs (Go Git Service)

23. GITLAB
Most comprehensive alternative to github
Community (CE) and Enterprise (EE) Edition (read OpenCore)
Large and great community

24. GOGS
Minimal requirements (Raspberry Pi may fit)
written in go
LDAP support

25. CONTINUOUS WHAT?
INTEGRATION!
Development practice where:
Developers push code regularly
(Build and) verified automatically
Developers (and PM) are notified of the code (and build)
status
Usually when state changes

26. CI - WHY?
Be aware of regressions and problems at an early stage
Increase productivity and project pace
Increase reliability of your deployments

27. CI - CAVEAT
Automated tests depends on
Quality of your tests
Coverage of your tests
Developers may only focus on succeeding tests
Poor tests results into bad code quality

28. CI - (SELF-)HOSTED SOLUTIONS
jenkins.io
drone.io
dockunit.io (abandoned)
gitlab-ci
captain (abandoned)
docker-jenkins

29. CI - RUNNING TEST
FRAMEWORKS
Look into static code analysis tools for you used language
Consider PMD to find inefficient code
Examples
Get an idea see Travis-CI - Building a PHP project
Using OCLint with Travis CI or Jenkins CI for testing C, C++,
Objective-C

30. CODE QUALITY
Hosted Services (Free as Beer for OSS.)
Scrutinizer CI
Code Climate
SensioLabsInsight

31. CONTINUOUS DELIVERY
Extends CI through deployment
Done by Pipelines
Jenkins Pipeline Plugin
Gitlab Pipelines .gitlab-ci.yml

32. DOMESTICATING DEVELOPERS
AND PROJECT MANAGEMENT
Many Software development methodologies
Kanban
Pair programming
Scrum

34. GITLAB ISSUE BOARD

35. SERVERLESS KANBAN FOR
GITHUB ISSUES USING GH-
PAGES

36. SOME MORE FANCY STUFF?

38. SLACK LOOKS PROMISING!
What if Slack servers are breached?
What if Slack is sold?
Is there a working export function?
Subscription

39. WHY DID MATTERMOST HAPPEN?
In 2014, Slack became popular in Silicon Valley, and our
company adopted it for messaging. But we had a problem–our
archives were in our old messaging app. After our subscription
expired, the old app wanted us to pay them to access our own
data (and export still didn’t work!). We hated being locked in. We
fumed. Our discussions, our research, our analyses, and
gigabytes of our carefully tagged in-game artwork was all held for
ransom by the service we had trusted. Slack was good, but it
was another proprietary SaaS app, and we’d just been burned.

40. SELFHOSTED SLACK
ALTERNATIVES
What are the best on-site alternatives to Slack?
Mattermost
Rocket.chat
Zulip
Five Open-Source Slack Alternatives

41. MATTERMOST

42. DO YOU LOVE FANCY STUFF?

43. #CHATOPS

44. DEVISION OF #YOLOOPS
ChatOps brings the context of work you are already doing into
the conversations you are already having. @jfryman
Remember Eggdrop and IRC?
Now combination of:
Hubot, Lita, Err
Mattermost, Rocket.chat, Zulip

45. CHATOPS

46. CHATOPS

47. CHATOPS

48. CHATOPS
ChatOps at GitHub
pagerduty: So, What is ChatOps? And How do I Get Started?
ChatOps: Everything about deployments right inside your
chat
Ansible and ChatOps. Get started
To Boost DevOps, Try ChatOps

49. CREDITS
SVN Structure
Git client/server
Gitlab Pipelines
Gitlab Issue Board
Serverless Kanban for GitHub Issues using gh-pages

50. CREDITS
Slack
Mattermost latest features
NewRelic ChatOps
PagerDuty ChatOps
Netways ChatOps

51. SLIDES
waja.github.io/software_development_from_devops_view/sw_dev_from_devops_osmc2016
DeckTape - PDF exporter for HTML presentation frameworks
Lizenz: CC-SA-3.0-DE
Mail: Jan Wagner waja@cyconet.org