You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Jira vs Github :: Agile vs Open Source

September 21, 2014 — JaZahn

A few years ago, my team got into Open Source. Specifically, we started writing all of our apps on github (as opposed to our SVN). We wanted to do this because we wanted to invite scrutiny. We never expected people to look at our stuff, we just felt that by putting it out in the open, we’d want to do better internally.

We went whole-hog. Organized stories with issues, organized sprints with milestones. It was pretty hot stuff. And it was all in the open. Potentially, someone could come by, see what we’re doing and offer to take a story from the backlog of issues. That’s open source. ish. We have a lot more we can do. A lot of growth to do.

Then we started using Jira. The board system within Jira Agile was excellent. Allowed for better organization, reporting!, and visual representations of work. It’s great. It’s Agile. But it also replaced what we were doing with Github issues.

We essentially replaced Open Source in favor of Agile. Our organization is great, we’re keeping track of things fantastically, but we’re no longer open. We don’t have transparency on what we’re working on anymore. People can’t potentially help. Our code is out there, but we’re not inviting. Our process is no longer out there.

So what’s our solution? We don’t have one yet. But what /can/ we do?

We need to put our vision statement out there. We need to put our plans out there. We need to expose what it is we’re doing. We also need to stay agile, keep our tools intact, keep our reporting.

This means we probably need to be duplicating efforts. Open Source and Agile are both hard work and organization. That they can’t line up and be the same effort is not a blocker, just an “oh well”.

Posted in Agile, ATG, Git, Open Source, SVN. Tags: , , , . Comments Off on Jira vs Github :: Agile vs Open Source »

Mobility Workshop

April 27, 2014 — JaZahn

gold stick figures sitting together working on their gold laptopsA couple of months ago, we had a very successful presentation on vagrant/puppet. Given by a developer, it sparked motivation in some devops enthusiasts to give a workshop. It went really well. (Vagrant Tutorial)

They had a great format with their workshops that seemed effective. They were super enthusiastic, which translated to super prepared. They had created a wordpress post that was a very detailed, step by step instruction on getting started.

The interest and effectiveness of this sparked motivation to do “other topics”. So I put together this tutorial on mobile development, “featuring jQuery Mobile”.

I thought the idea of something where I had the material prepared beforehand and could just say “go” was a great place to start. This shouldn’t be a presentation, it should be an opportunity for people to get their hands dirty.

I was running through tutorials and found a lot of them had put their code on github. At some point I had the idea to use branches to “step” through the tutorial. The way I envisioned the workshop going was to start with nothing, and build out a mobile app through logical steps — as a lot of tutorials do. Do a header, do a menu, do a list, do a link, do a transition, do a search. Coming up with a list of “things to do” was easy.

Putting it together with github also meant I could just put the directions in the base readme and it would be a completely self-contained tutorial. (Not to mention, having it in git allowed me to force people who I know don’t want to make the switch out of SVN to use a VCS that is so much nicer.)

Anyway, the finished draft took a long time. It was a lot of easy stuff, but time consuming.

(Mobility Workshop)

The most important part came after the draft was finished. I gathered some team members and some cross-team members — basically whoever would come sit with me and had them run through it to see if it made sense. They were brutal. It was great. A lot of this work happened after hours, so the language was at times, very stream of consciousness. Having people with varied familiarity with the topics covered allowed for some invaluable revisions.

Overall, the workshop proved to be a wonderful exercise in collaboration and teamwork, and regardless of how the actual workshop goes, it has left me better than I started, so that’s good enough.

Posted in Design & Modeling, Development, Open Source. Tags: , , , , , , , . Comments Off on Mobility Workshop »

Getting Travis-CI to work with a PHP Project

March 21, 2013 — JaZahn

First off, Travis CI is only usable through github. It’s a great service that allows tests to be run before pull requests are merged, helping to ensure code stability. It’s a very new service, and PHP support is in flux. Almost daily information changes. So I fear this will be outdated tomorrow. Regardless, I wanted to get this written down.

The magic all happens in the .travis.yml file. It’s a config file that tells travis what to run. It only has a few sections, but they can be tricky. Here is the example .travis.yml for PHP:

language: php

# list any PHP version you want to test against
php:
  # using major version aliases

  # aliased to 5.2.17
  - 5.2
  # aliased to a recent 5.3.x version
  - 5.3
  # aliased to a recent 5.4.x version
  - 5.4

# optionally specify a list of environments, for example to test different RDBMS
env:
  - DB=mysql
  - DB=pgsql

# execute any number of scripts before the test run, custom env's are available as variables
before_script:
  - if [[ "$DB" == "pgsql" ]]; then psql -c "DROP DATABASE IF EXISTS hello_world_test;" -U postgres; fi
  - if [[ "$DB" == "pgsql" ]]; then psql -c "create database hello_world_test;" -U postgres; fi
  - if [[ "$DB" == "mysql" ]]; then mysql -e "create database IF NOT EXISTS hello_world_test;" -uroot; fi

# omitting "script:" will default to phpunit
# use the $DB env variable to determine the phpunit.xml to use
script: phpunit --configuration phpunit_$DB.xml --coverage-text

# configure notifications (email, IRC, campfire etc)
notifications:
  irc: "irc.freenode.org#travis"

Not included libs

Currently this will not work. Their phpunit is requiring libraries that aren’t included in the vm that’s created. Regardless of if your project is using these libraries:

before_script:
  # everything after this point is needed to just use phpunit
  - pear channel-discover pear.phpunit.de
  - pear install phpunit/PHP_Invoker
  - pear install phpunit/DbUnit
  - pear install phpunit/PHPUnit_Selenium
  - pear install phpunit/PHPUnit_Story

Database usage

I use mysql currently. The problem I hit was you can create users, but you can’t grant them privilages. So you HAVE to use the default root user with no password.

env:
  - DB=mysql

# execute any number of scripts before the test run, custom env's are available as variables
before_script:
  - mysql -e 'CREATE DATABASE `quizmo_dev`;'
  # The following is fine, but travis won't allow granting privilages
  # - mysql -e "CREATE USER 'quizmo_dev'@'localhost' IDENTIFIED BY 'quizmo_dev';"
  # - mysql -e "GRANT ALL PRIVILEGES ON *.* TO 'quizmo_dev'@'localhost' WITH GRANT OPTION;"
  # migrating adds all tables
  - quizmo/protected/yiic migrate --interactive=0

Notifications don’t work

I’m assuming this is something they’ll fix soon. I’m just trying to use email notifications — but it never sends an email.

Posted in Development, Open Source, PHP. Tags: , . Comments Off on Getting Travis-CI to work with a PHP Project »

Continuous Integration with PHP on Travis CI and Github

March 21, 2013 — JaZahn

People on high have been preaching the wonder of continuous integration for a while now. It’s been all about Jenkins forever. Jenkins is still the #1 choice for most people, but I recently ran into Travis CI and at least short term, this is going to be the solution for our shop.

What is Continuous Integration for PHP?

CI to most people involves building and running integration tests. PHP clearly doesn’t build, but good PHP still has unit tests / integration tests / functional tests — so CI for PHP is running those tests before code merges.

What makes Travis CI good?

Probably ease of use. There is no setup of a “travis server”. It’s a service that they run. You hook it to a repo you have access to and set up a config file and it’s good to go.

But this only works with github?

That’s probably the biggest detractor. It’s currently built exclusively for use with github. Which is awesome for github projects, but not every project can be on github. We don’t always have control over where our repos are — and not everyone is an open source person.

Posted in Development, Open Source, PHP. Tags: , , , , , . Comments Off on Continuous Integration with PHP on Travis CI and Github »

Deciding on a Style Guide

December 15, 2012 — JaZahn

Recently a couple of groups here at work were brought together to try and standardize on a few things. The Software Development Community of Practice! Style guides came up. Everyone said they had no style guide and everyone agreed having a style guide would be worthwhile.

I had spent some time writing a style guide (customizing) so I was interested by this. I got to reflect on my style guide, how I’ve referred back to it in the year since I put it out there, and how I think it has helped or could help in this forum.

See the reason I created this style guide is not all that different from the reason these communities of practice are looking to create style guides. I was/am writing open source, and on the hope that someone will want to contribute to the project, I want a rule set defined so people won’t submit something unreadable.

For the community of practice, it’s a little different, but the spirit is the same. What they want is to have the option to point at something when a fellow developer is writing horrible code. The premise is you have a new developer and they don’t know how to write clean code.

The problem I have with this is everyone knows how to write clean code. And by everyone, I mean every professional software developer. If they’re not writing clean code, they’re not professional. Now that of course means if we are using student employees or taking in work from unknown outsiders (Open Source), that we are risking poorly written code being introduced and should therefore have a style guide. But if the premise is to have something for professional developers, I think it’s a waste of time.

Most style guides are 95% the same and we’re not talking about trying to enforce the 5% that is going to be different between individual developers. If ever a problem comes up with software developers where one is trying to say another’s code style is wrong, they should be able to say “google a style guide to see what best practices are” and be done with it.

Sadly, I’ve wasted more time arguing this than it would have taken to just agree, pick a guide that no one will ever use and move on.

Posted in Development, Open Source. Tags: , , . Comments Off on Deciding on a Style Guide »

A little bit of Agile, a dash of Open Source, and a pinch of ITIL

October 30, 2012 — Michael D. Hilborn
Agile, Open Source, and ITIL

From left to right: Agile, ITIL, and Open Source: An (un)holy trinity?

So I’ve hopefully started what will become a multi-part series about integrating Agile, Open Source, and ITIL into an overall strategy for delivering web services. You can find the first part on my personal web site. WARNING:  The first post is simply a high, very high, overview of the three methodologies, so you may find nothing new in there.  Indeed, here’s a snippet speaking to that very fact:

First, an admission: Open Source, Agile, and ITIL are nothing new to the realm of IT; all have been around for years, if not decades, and many industries have embraced them in some form or another. So the fact we are now incorporating these practices into our work might not seem exactly novel and, if I was strictly speaking about incorporating just the individual practices into our work, such an assertion would be correct. But I’m talking about merging all three, and a quick Google Search on “implementing,” “incorporating,” “combining” or “merging” this trinity doesn’t exactly return a cornucopia of results. So maybe what were doing is somewhat novel, after all.

Posted in Agile, Development, ITIL, Open Source. Tags: , , , . Comments Off on A little bit of Agile, a dash of Open Source, and a pinch of ITIL »
«
»