Presented at SyncIpswich

Following on from the success of SyncNorwich, Carl Farmer has set up SyncIpswich - a regular event for technologists, creatives, entrepreneurs and graduates to meet up and talk in with the aims of growing the community in Ipswich.  Paul Grenyer recommended me to Carl as a speaker and after letting Carl know that I'm not proficient at speaking (yet) I agreed to come up and give my presentation on Continuous Delivery at 7digital.

Despite fighting with the traffic in Ipswich town centre I made it just in time and spoke in front of a crowd of roughly 60 people.  As before, my slides were done in roughly 15 minutes and I fielded questions from the audience for about another 15 minutes more.

After a short break I was followed by Richard Astbury giving an introduction to the Azure platform where he deployed an empty MVC App from his laptop and then a simple Hello World node.js site from his Raspberry Pi at home, which was rather impressive and demonstrated how smooth it can be.

We then gathered at the nearby pub where we broke into a few discussions about the advantages and disadvantages of feature branches among other things and I admired the view of the boats in the marina before I left for the nearly 2 hour drive home.

I had a great evening and it was good to talk to people outside of London and once again be reminded that we don't have the monopoly on smart, inquisitive, talented developers doing great things.  Thanks to Carl for arranging it and Paul for recommending me.

Team Transformation Presentation for London Continuous Delivery Group

On Tuesday 19th March I gave a short presentation on the steps 7digital took to transform our team in order to facilitate Continuous Delivery.  This was held at Skillsmatter for the London Continuous Delivery group.  I also managed to rope in a few of my colleagues for a discussion panel after my short set of slides

I'm really grateful to Hibri, Goncalo, Matt and Rob for coming along as I felt that having more than just my voice would add to the credibility of what I said and it would also be more interesting.

You can see the video on the Skillsmatter site and these are the slides.  James Betteley also posted a running commentary of the event where you can read some of the discussion which took place.

2012 Retrospective

As all Agile methodologies teach us, the action of looking back and reviewing your progress is an essential part of improvement. As such, I'm going to try and run a simple retrospective for my 2012.

Review

Lets start by reviewing the last year on a timeline. As it's such a long period I'll stick with monthly increments and pick out notable events.

January: 
 - Discovered WebGL and my messing about got picked up by LearningWebGL.com

February: 
 - Nothing of note :(

March:
 - Attended first GDC Meet a Mentor event
 - Started planning the "Devs in the 'ditch" events

April:
 - Organised a successful first "Devs in the 'ditch" event
 - Organised the 7digital stand at the "Find your Ninja" event.
 - Attended GeekGirl Meetup in London

May:
 - Organised and helped man the 7digital stand at Silicon Milk Roundabout
 - Attended the Progressive.Net Tutorials

June:
 - Organised second "Devs in the 'ditch" event

July: 
 - Became a STEM Ambassador

August:
 - Nothing of note :(

September:
 - Organised third "Devs in the 'ditch" event
 - Stepped up to take over the ACCU Mentored Developers from Paul Grenyer and thereby co-opted into the Committee.
 - Kicked off an ACCU Mentored Devs book group on JavaScript: The Good Parts
 - Attended DDD10

October:
 - Organised and presented at the fourth "Devs in the 'ditch" event.
 - Presented the same talk at ACCU London
 - Became the API Team Lead Developer

November:
 - Took part in a Year 9 Careers Speed Networking event as part of being a STEM Ambassador
 - Presented to undergraduates at the Middlesex University IT Careers Forum
 - Passed Grade 1 of Cello

December:
 - Presented at APIDays 2012 in Paris

Other Stuff:
 - Adopted a lovely Cat
 - Attended at least 18 events, and spoke at 3.
 - Attended 4 Weddings (one of which was a surprise)
 - Lost just over 10lbs in weight and no longer officially overweight
 - Visited Portugal, twice, and Paris.
 - Finished reading 5 books, and started at least twice as many.
 - Wrote 12 blog posts
 - Created 13 Github Repos

Good / Bad / Change

Now is the part where I reflect on the year, using items that I brought up in my review as an aid and write down what I felt went well, went badly and what I'd like to change going forward.

Good

- Finally started speaking at community events, I'd been wanting to do so for so long, but was afraid
- Attended many events and conferences
- Improved my overall health :)
- Began organising events and learned a lot from this
- Began putting myself forward as role model to younger people as part of the STEM Ambassador work

Bad

- Didn't read or finish as many books as I'd have liked

- Didn't really travel or visit many places

- Only wrote a few blog posts

- Didn't finish any programming projects I started

- I wanted to have done more with WebGL

- I seem to have coasted through the first quarter of the year

Change

- Must commit to projects and finish them before starting new ones
- Must commit to finishing reading books that I start before starting new ones
- Try to read more books
- Blog more, it improves writing and communication skills
- Stop procrastinating!

Goals & Actions

Normally the team would vote on which topics they'd like to promote to goals and actions but as it's just me I'll pick three that I feel are the most important.

Goal: Make 2013 The Year of Reading
Action: Read and finish at least one book a month.  Preferably a technical book but any kind counts. I've put the GoodReads Challenge in my sidebar as a reminder.

Goal: Present and speak more.
Action: Volunteer for more events. I did three last year, I'll aim to improve on that.  I've already put myself forward for an event with the London Continuous Delivery group in March

Goal: Visit a new country
Action: I'll make a point this year to take holiday somewhere that I haven't been before.  It doesn't have to be far, just somewhere new to me.

Retrospective Close

I feel that this was indeed a useful exercise.  It took a couple hours to do and write up mostly because a year is a long time period and I wanted to go back through my calender and emails to ensure I picked up as many events as I could.

Looking back I can say that that I've both done a lot of things, but also not enough things.  I picked up new items such as speaking and becoming more involved in the ACCU, but I also let things slip such as blogging and reading.  It's so easy to let things slip by you when they happen one day at a time.

I'm hoping that 2013 will continue along the trend that I started as there is so much that I want to see.  At the end of the year I will run another retrospective and compare it with the actions above, which should be interesting!

APIdays 2012

On Monday 3rd and Tuesday 4th December Paris held host to the first international API focused event in Europe - APIdays.io.  Myself, and my colleague Hibri, eagerly took part and we gave a short presentation on how 7digital grew their public API, the lessons we learned and the effect it had on the way we work.  You can view the slides at the end of this post.

We received great feedback from our slides - it felt as if many people are just getting started in the world of APIs whilst 7digital have had their public API for many years and that they were very interested in hearing our real-world story.

The format of the event was a little odd, with talks in slots of less than 30 minutes, which on the plus side meant that we got to see a lot of different viewpoints and experiences but that there wasn't enough time for anyone to get deep into a topic.  I'd like to suggest that a technical track has available 1 hour slots for anyone who wants to host a full-on technical presentation and debate - it felt like we barely scratched the surface in less than 30 minutes.


It was a great couple of days, and the first time I'd ever been to Paris.  I'm hoping that this event becomes a regular conference and that next time we can get far more technical with the content and swap the really gritty stories of lessons learned.

Questions from my Continuous Delivery Talk

My short talk on how we do Continuous Delivery at 7digital generated many questions from both the audiences at Devs in the 'ditch and London ACCU.  Also, a couple more were asked on Twitter after the events.  Here are are the ones I can remember and my answers.  If anyone has any more questions please add them to the comments.

Can you choose which release version to deploy?

As we deliver web-based services, not products, we are always aiming to release the latest version which is almost always the of HEAD of the Master/main integration branch merged into a Release branch.

We rely heavily on TeamCity to trigger our deployments as well as our continuous integration.  It includes a feature called 'pinning a build', which prevents it or it's artifacts from being deleted in a clean-up policy.  It also allows us to reference these artifacts in another build, such as a deployment build.

Once the Release branch has been updated with the changes in the HEAD of the Master branch, and all of the tests have passed and we are happy, the build is 'pinned' in TeamCity and we kick off the Deploy to Live  build which picks up the pinned artifacts and deploys them to the production servers.

We can choose what build should be pinned and therefore what artifacts are released to Live.  We don't necessarily version our releases because we never refer back to the versions and only a single version is ever live at one time.

How do you do a rollback?

We 'un-pin' the build and artifacts of the 'bad' release, 're-pin' the build and artifacts of the previously known 'good' release and run the Deploy to Live step once again.  This effectively does a 'roll forward' with known good artifacts.

What role do QA have in the process and do they trust the automation?

QA are generally involved throughout the process.  Together with the Developers we will both fulfill the traditional role of a BA and analyse a piece of work, creating Acceptance Criteria which normally form the basis of the Automated Acceptance Tests.  Also, this means that QA are fully versed in the feature or change when it comes to UAT and explanatory testing and together we can make a judgement call as to whether a change actually needs QA manual testing or is sufficiently covered by the automated tests.  Being involved all the way through gives them confidence in the process.

A point to make is that we don't have a QA Team as such, each development team includes a QA person and a Product Manager.  We all sit together and attend the daily stand-up so everyone is aware of what is taking place, the mood of a change and can jump in at any point.

How do you handle large features/pieces of work?

We hold an analysis session within the team, including the developers, QA and Product Manager to break down the work into as small a user story as possible, aiming for under a day.  Each story needs to be a single contained piece of the functionality which can be released on it's own.  This is not always possible and in these times we employ Feature Toggles which will hide a feature until it is ready.

What we don't do is have feature branches.  This is something that must be avoided to ensure that we are always integrating all changes and any problems are highlighted as early as possible in the development cycle.

What about database schema changes?

We use a tool we developed internally, but have since Open Sourced: DBMigraine.  There are a couple of blog posts on the 7digital Dev Blog here and here which explain it in more detail, but in essence it builds databases from a set of creation scripts applies migration scripts, and performs consistency checks between databases.

Using this tool we build a database from the scripts and migrations at the beginning of each Integration test suite and run the tests against the new schema.  This should hopefully flag up any major problems before these migrations are also applied to the Systest and UAT databases which are integration points for all of our apps sharing the same database.

It's worth noting that we try to avoid destructive migrations, but this process has allowed us to gradually delete unused tables in a tested manner.

--------------------------------------
Edit - new Question from @AgileSteveSmith

What cycle time reductions have you seen?

In my reply, I linked Steve to the following two posts on the 7digital Developers' Blog related to productivity at 7digital: "Productivity = Throughput and Cycle Time" & "Development Team Productivity at 7digital".

The posts illustrate, with data tracked from our own work items, that there was an incredible reduction of Cycle Time in over the course of 2009 to 2011 - you can even see the massive spike at one point where things got worse before they got better, as I mentioned in my presentation!

A full report was put together, with even more charts and graphs, which can be downloaded from the second blog post.

Continuous Delivery at 7digital

It began with an off-hand comment on the ACCU General mailing list that at 7digital we release on average 50 times per week, across all of our products.  I thought nothing of it, virtually all of our products are web-based, which makes it relatively easy to deploy on a regular basis, but it seemed that others were interested in how we do it and so I was cajoled into giving my first presentation.

I began by explaining what we understand as Continuous Delivery - a set of repeatable, reliable steps which a change must go through before being released.  In our case most of these steps are automated.

I described where we came from and how we approached the change, in both a technical and business manner, and where we would like to see ourselves going.  I then included a flowchart of  A Day in the Life of a Change at 7digital, which Prezi allows me to 'bounce' around as we hit different stages in the pipeline.

I answered many questions clarifying how we handle rolling back a bad release (we actually 'roll-forward' with artifacts of the previous 'good' release), whether our QA team are comfortable with the process (yes, they help write the criteria),  and how large pieces of work are tackled (we try to break them down into deployable pieces no bigger than a day).

Here are the slides:

Continuous Delivery at 7digital on Prezi

(Cross-posted on the 7digital Dev Blog)

Update: I have posted some of the questions I got from the audiences here.

DDD10 - The day of REST

I was on holiday when the sign-up for DDD10 went live and I missed the window by about 5 minutes.  Still, I added myself to the Waiting List in hopes that it would work and on Monday I got an email letting me know I had a place - Excellent!

Reading through the schedule, I decided to take advantage of those which relate to my current role as a Lead Developer in 7digital's API Team, which meant the three REST talks.

The first session, Jacob Reimers' "Taking REST beyond the pretty URL", failed to meet me lofty expectations.  It was more of an introductory talk, which did not go much beyond level 2 of the Richardson Maturity Model.  From the questions of other attendees, this talk did get some people thinking, with questions wondering how interactions could be reproduced using only the HTTP 1.1 Verbs, but I was not one of them.  It is at times like these that I realise just how forward-thinking London is and that there are many places where this kind of approach is not a given.

The second REST focussed session I attended was Dan Haywood's "Restful Objects - a hypermedia API for domain object models" and simply put, it boggled my mind, but not in a good way.  It was obvious that Dan had done his research, but when it came to his implementation, something had gone terribly wrong, and it was like entering the Twilight Zone.  Restful Objects is a specification which aims to standardise and genericise REST.  I'm not a fan of "generic".  In my experience anything that aims to be generic ends up being complex, difficult to use and maintain, and incredibly inflexible, as such I mentally flinch whenever someone uses that word to describe a system.  

The biggest things which stand out in the spec is the inclusion of an "action" in the URI and a requirement for ~/{resource}/invoke endpoints - this misses the point of using the verbs on the resources themselves!  It is littered with URIs such as http://~/objects/ORD/123/actions/placeOrder/invoke. It also advocates exposing the properties on the URI too, which I believe pulls this property out of the context of the resource.  Also, it seems to advocate exposing your domain as the resources thereby creating systems which end up with tight coupling and knowing too much about each other.

Dan does caveat his design by stating he believes there is no need to hinder and complicate your system too much if it is to be entirely internal.  I disagree, to some extent, all of these systems will become "public" in that they will eventually be integrating with other systems and teams that you do not have direct control over and therefore need to minimise the coupling.  At 7digital we design all of our internal APIs with the same approaches and philosophies as if they were publicly exposed, and at some future date, that may even become the case.

Finally, there was Mark Rendle's session "Simple.Web 101".  Although, not a session focussing on REST itself, but on a REST framework.  I had seen Mark unveil Simple.Web back in June at the Progressive .Net Tutorials and I was curious to see how far it has come along. At 7digital we mostly use OpenRasta, but we have a few APIs written in NancyFX too and we're always open to finding new tools which may be better for the job.  As this was only a 101 talk it didn't go into enough depth for me to see what the improvements have been, but Mark is giving a free in-depth discussion this SkillsMatter this Monday.  Unfortunately I cannot make Mondays as I have my Cello lessons, but I will catch the podcast later.  

Outside of my mini REST-fest, I attended Neil Barnwell's talk on "CQRS and Event Sourcing... how do I actually DO it?".  I have unwittingly managed to avoid learning anything about this area and was hoping Neil could educate me fully in only an hour, which I feel he succeeded to do.  It was an overview with some code examples thrown in which have removed the mystery for me.

Out of curiousity, I attended Jimmy Skowronski's talk "C# + PowerShell = happy couple" and learned a little about writing your own commandlets.  Finally, Garry Shutler took us through "10 practices that make me the developer I am today", which he described as a retrospective of his career thus far and hoped to impart some useful lessons.

I had a great day and I wish to thank all of the organisers and everyone who helped and I'm already looking forward to next year.