Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Friday, July 27, 2012

Kuali Implementation Development Pre and Post Go Live


I named this such because I think it effects all Kuali software implementations. This post is about the concept that pre and post-golive are actually 2 separate implementation projects. Many of you are probably saying, "Of course! You have customization mode and support mode." That may be true, but that is not what I want to point out. I am speaking specifically to development process and strategy rather than the administrative impacts of the application.

I have only had the opportunity to witness a few implementations go live, so I cannot speak to every implementation out there. From what I have witnessed though, I will say that in each case development continues on almost as if nothing has happened. This may in part be because prior to go live, implementations are already preparing by mimicking production.

After some time, there is a kind of evolution that occurs as development teams mature and become more familiar with their software and processes behind maintaining their software. For example, the University of Arizona is starting an initiative where they are employing a release process paradigm called Git flow. One of the primary issues before and after go live is the matter of controlling fixes and features as they flow from environment to environment. Git flow is a paradigm that is tempered to the point where support software has been written to support it and enforce its tenets. I wish them the best of luck with their initiative and look forward from learning from their experience.

I want to share an idea that I think many have already thought of or at least had it in the backs of their minds. I can tell because of how Continuous Integration has embedded itself into our release cycles and environment management. There's been talk of Continuous Deployment, but still on a release cycle. It's like we're at the cusp of realizing something.


What if the world of development before and after go live are actually so far from each other, that they become entirely different processes? I recently came across this article about a month ago and at first I really didn't think anything of it. I didn't even think it applied to me in any way because I don't plan to ever work for github. I then realized that github is a SaaS just like KFS, KC, and just about anything built with Rice. As soon as that occurred to me, I hurried back to read about Github Flow.

Scott Chacon is discussing why they don't use Git flow at github. Here's what really struck me from what he stated:

"We don’t really have 'releases' because we deploy to production every day - often several times a day."

By now you are spraying whatever you were drinking earlier out of your nose, right? I know because that's what I did. They deploy to production every day. Some implementations do that. Several times a day is what we all wish we could do. Can you imagine the software agility? To be able to drop in a fix with little to now administrative overhead?

"If you deploy every few hours, it’s almost impossible to introduce large numbers of big bugs."

It's true. Once, I had found a tremendous bug on github. I thought I was so cool I posted an issue. Before I could blog about it, the bug was fixed. I had to retract my blog. Big bugs don't exist. When you can deploy fixes with such agility, your only problem is prioritizing which ones first.

"We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it."

I said it before, but they made it their mission to defeat administrative overhead in order to provide this capability. Every employee feels comfortable not just because they do it regularly, but because they made it simple and easy.


Now that we know github's process, what if we wanted to follow this? Do we have to use git? I don't think so. Github's process isn't anything specific to git. Of course, they have their own tools like hubot and of course their UI. Each of those is exclusive from git which means SVN would be just as applicable. I think probably the biggest obstacle would be the application startup time. The application has to go down for deployment, so what then of restarting it? In production, I expect that institutions will probably have failover configured. One node can cover for another while it is updating and back again. Since optimal startup requires failover and the only environment that will probably have it is production, this implies there's only one environment after go live. This probably makes you a little nervous. It may even make you shudder. Imagine though that what Scott explained is true and that major bugs are wiped out by this process and that everyone can follow it (even business analysts, graphic designers, or web developers).


Prior to go live, institutions are concerned with pruning the system, conversion (data migration), environment setup, quality assurance, managing vendor sources, and configuring their software. Preparing for go live is incremental and each increment is treated like a release. These releases are scheduled. Sometimes close together and sometimes far apart. Institutions will have some environments they deploy to several times a day, but those are generally not releases. Those are development modifications. These are not changes that have been QA'd and part of a release. There will be eventually be a release.

Post go live, the need for releases doesn't exist anymore. Most of the work is support issues or new feature requests. This is pretty much like how github operates. I think Scott is right.

No comments:

Post a Comment