It’s easy to see how code changes work. A client asks for a new feature, then at a later date that feature appears on their site. But there are many other steps that go into adding features to web sites. This article is designed to be a very high view of a very simple workflow. It is intended for clients and other interested parties, but it’s important to note that this is an extremely simplified example. A real project workflow for a single task could have many, many more steps. I also designed this sample workflow to be very language agnostic. It should give everyone a general idea, but for a much more in depth look give me a call or shoot me an email.

Workflow Chart
Workflow Chart

This example has two developers. Some clients only have one developer and some have several. It also does not show anything like graphics work, design work, or other very important parts of making changes to websites.

First every change, no matter how big or small starts with a ticket in the tracker. If your a current client, you have access to the tracker and can see your tickets and their statuses. You also get emails when ever a new ticket is entered, or an old ticket is updated. For this walkthrough were going to assume you want to add shipping and handling to an existing order form.

In our example each developer takes a ticket and pull’s the most recent version of the source code. This makes sure that they have the most recent version of the code base to work from. Any changes they have made locally will be preserved and new changes others may have made will be imported.

The next step is to write a failing test. This is done so that we can confirm issues, and so we can tell when we have completed the request. For example, you want your order form to have shipping and handling. We would write a test to make sure shipping and handling was included on the order form. This would of course fail, because we haven’t added it yet, but it would give us something to measure against to determine when we had finished adding it.

Next comes the fun part. We then write all the code needed to display shipping and handling on the order form. When we think where done, we test it again, and see if it passes. If the test we wrote previously passes , then were done, and we can safely say that the shipping and handling is implemented on the order form. If the test does not pass then we continue to write code and correct errors until it does.

We then commit the changes. That is to say, we save them in a more formal sense. Imagine a word document. You may save it several times while working on it, but at some point you have to email it. Once emailed, it’s really hard to un-email, so you make sure that it’s just the way you want it before you attach it to the email message. This may involve several saves of the word document, but ultimately you only send one.

If there are more tickets we start the process over again. We don’t do the entire process at once because several changes may be needed to effect your over all higher level goal. For example, we added shipping and handling, but we may need to add taxes, and grand total as well. Those three changes are what you want to see published, not just shipping and handling. This also allows, in our example workflow, for one developer to work on shipping and handling, and another to work on taxes. This doesn’t decrease the total time spent making the changes, but it does reduce the real world time. So for example if it takes 15 mins. to add taxes and 15 mins. to add shipping and handling. The total time spent will still be 30 min. but only 15 mins. would have gone by (because two people are working on it at the same time).

Once all the tickets are complete, we would then push those changes. This would be basically the same as pressing send on the email. You may attach several files, save several drafts, but eventually you need to actually send the email so that others can see it. A push usually contains several commits.

The integration test server now takes over. It’s mostly automated, and it tests after every commit. This is very important for two reasons. First it runs the tests (the ones previously written) and makes sure that the code from the separate developers integrates properly. Basically, it’s like an automated way to make sure your email didn’t contradict your co-workers email. Second it runs the entire test suite in a environment that is very different from development and more like production. This means that if there are any errors caused by different versions of operating systems, or installed versions of languages, the integration server should catch it. It’s not perfect, but running a full test suite only takes a few minuets and can save thousands of dollars. It’s also very automated and requires little intervention. In short, it’s totally worth it.

Then if the integration tests pass, we can then deploy the code to production. If it does not, then we create tickets to fix the issues detected. More often then not, the issues are simple minor issues or failed mergings (the work the two developers did conflict somehow). In almost all cases the problem is corrected in a matter of minuets. A new version of the code is _push_ed and integration testing is completed successfully.

Deploying of the code it the last step and makes the code live on the server so you and your user base can see it.

To be fair this is a very over simplified process. It’s meant to give you a general idea. You can add more developers or go down to just one. The process doesn’t change. However, this is not a complete example.

Take the shipping and handling. Lets say your ticket is to add shipping and handling to the order form. Thats a good ticket, but the tests are broken down into several tiny steps. For example, we need to test that it is displayed properly, and that it is calculated properly. So each ticket may have several tests. In turn when writing code to add shipping and handling, it would likely effect the previously written tests relating to total. So fixing the new shipping and handling tests could break other tests that would then need to be fixed.

The important part, is that while this does give a very simple and slim version of how a ticket makes it from the tracker to your website. It’s very important to note that this is not a real sample, and most tickets will be much more complex. If you would like a more detailed example just give me a call and we can walk though one of your tickets, or, if your not a current client, look at one of your requirements and create a sample ticket.

Coteyr.net Programming LLC. is about one thing. Getting your project done the way you like it. Using Agile development and management techniques, we are able to get even the most complex projects done in a short time frame and on a modest budget.

Feel free to contact me via any of the methods below. My normal hours are 10am to 10pm Eastern Standard Time. In case of emergency I am available 24/7.

Email: coteyr@coteyr.net
Phone: (813) 421-4338
GTalk: coteyr@coteyr.net
Skype: coteyr
Guru: Profile