Re: January 8 2014 PA Topic - DevOps, Continuous Delivery, and Agile Teams

[Eric Myhre]

Kyle, I really enjoyed your mention of Hubot. I'd looked at that before, but didn't really understand why I would want a terminal in my irc. After your story about how easy it is to increase transparency by putting those operations in the middle of a flow that's already multi-person, it kind of clicked.

Could you talk more about the monolithic repo approach? I'm fully sold on some benefits to that approach -- namely that when I do a huge refactor that crosses projects, I can do it all in one commit. But other things still kind of scare me -- for example the branching when there's dozens (or hundreds?) of people committing every day seems to quickly outgrow what any gui I've ever seen can deal with and be reasonably informative. What are your experiences?

[Kyle Boon]

We have a single repository with many projects inside it. We use gradle to build the entire system with a single command, but you can also build a single project if you need to. There are about 30 separate components in there right now. We actually still have 2 applications that haven't been combined into this repository, and we haven't added the source of external dependencies like google has. On my laptop I can build the system from scratch including dowloading external dependencies, compiling, running all tests (unit, integration, functional) and static analysis tools in 19 minutes. Subsequent builds are much faster because gradle only builds what needs to be built after I make a change.  This has worked extremely well for us and I would definitely do it again.

Benefits:

* all projects reuse the same build tooling. this helps consistency. All of our projects use the same groovy static analysis tools with the same version and the same rules turned on. 

* very easy to add a new component. Because we're still ripping apart the monolithic 'legacy' application and moving it to services, it's a bonus that all someone needs to do to create a new service or library is create a directory, add a build.gradle file and apply a base build script. 

* We don't need to worry about versioning every project separately. We care about one thing, the SHA of the commit we deploy. When someone makes a change to a library they don't have increase a version number and then go make a change in every downstream project that might use it. 

* Developers don't need to use maven local much if at all. 

* Updates to snapshot jars in artifactory won't break the workflow for developers who haven't fetched the latest code.

When we started going down the SOA route we talked about using a single repository and decided we didn't like the idea. Then we had 10 repositories all of a sudden. The first time I saw 4 separate pull requests to 4 separate repositories and if you merged 1 you had to merge all of them in order to not break the build, I knew we had to do something. 

Our github process involves everyone having their own fork. Each developer starts a feature branch on their own fork and works there until its ready to be merged. Then they create a pull request to the organization owned repository. That pull request is built by jenkins before merging and the github commit status is set. Then as people review the code we know that the entire system builds. When we're ready, we merge the code.

We use a homegrown app we call pullreq (www.pulreq.com https://github.com/adanperez/pullreq) to help manage the number of pull requests we have. Right now there are 19 open pull requests and thats probably a little less than average. We use a simple naming scheme to let people filter out things they don't care about. Pullreq can also let you flag specific files of interest, so it will highlight things that you might want to make sure you review. 

I think this makes branching easier because we don't have to manage branches across multiple repositories as often as we used to. With each project that has been incorporated into the single repository, this has gotten better.

We still have 2 legacy applications outside of the single repository, as well as all of our chef code in a separate repository. So there are usually 4 repos to manage when we're ready to deploy. I'd love for them all to be merged into the single repository over the next few months. 

On Fri, Jan 10, 2014 at 8:55 AM, Eric Myhre <ha...@exultant.us> wrote:

Kyle, I really enjoyed your mention of Hubot.  I'd looked at that before, but didn't really understand why I would want a terminal in my irc.  After your story about how easy it is to increase transparency by putting those operations in the middle of a flow that's already multi-person, it kind of clicked.

Could you talk more about the monolithic repo approach?  I'm fully sold on some benefits to that approach -- namely that when I do a huge refactor that crosses projects, I can do it all in one commit.  But other things still kind of scare me -- for example the branching when there's dozens (or hundreds?) of people committing every day seems to quickly outgrow what any gui I've ever seen can deal with and be reasonably informative.  What are your experiences?

--
--
To Post: email to practic...@googlegroups.com
To Read Posts: http://groups.google.com/group/practical-agile?hl=en?hl=en
To The Website: https://sites.google.com/site/twincitiespracticalagility/

To Unsubscribe: email topractical-ag...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Practical Agility" group.
To unsubscribe from this group and stop receiving emails from it, send an email to practical-agi...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

--
Kyle Boon
Technology Lead
Bloom Health
cell: 513 824 1282
email: kb...@bloomhealthco.com
www.gobloomhealth.com

CONFIDENTIAL COMMUNICATION:
This email may contain confidential or legally privileged material, and is for the sole use of the intended recipient. Use or distribution by an unintended recipient is prohibited, and may be a violation of law. If you believe that you received this email in error, please do not read, forward, print or copy this email or any attachments.  Please delete the email and all attachments, and inform the sender that you have deleted the email and all attachments. Thank you.

[Christopher Bartling]

Great write up Kyle.  Much appreciated.

Regards,

-- chris --