In an environment of rapidly-changing technology and approaches, an internal tech conference can be a powerful and effective way of spreading new ideas and practices and sharing learning & experience. Having organised and run several internal tech conferences (at different organisations), Victoria Morgan-Smith and I decided to write about our experiences in an article for InfoQ: Internal Tech Conferences – How and Why. We also interviewed several other people from various organisations who have also run internal tech conferences in order to give a broader perspective.
Our aim was to inspire and enable other people to develop and run internal tech conferences in their own organisations, building on the experiences of the teams and organisations in the article.
In this article we draw on our personal experience of running internal tech events at companies we’ve worked with, along with reflections and advice from people at Paddy Power Betfair, Callcredit Information Group, ING and others. You’ll find further reading & listening material at the end of the article – there is so much inspirational work happening in so many organisations.
Key points from the article are:
- Software engineering today is as much about people as the technology itself: an internal tech conference can give a huge boost to your organisation’s social capital – that currency by which relationships flourish.
- The format you choose for your internal tech conference depends on what you want to achieve from it: it can be “by the people for the people”, or a showcase to celebrate achievement. You can keep the audience or speakers to just a single department, or invite other divisions, or even invite external speakers and/or audience.
- Making the event a success takes effort: choose your speakers well, and mentor themas they prepare their talks. Work on the logistics – it’s the little things that count.
- Remember to have fun: ‘death by PowerPoint’ will mean people remember the event for the wrong reasons!
- Follow through: for a lasting impact, keep sight of the outcomes you seek and be ready to work with others to keep the momentum going.
We hope that the article is useful for people thinking of running or improving their own internal tech conferences!
Thanks to everyone involved: people we interviewed, the amazing InfoQ team, and to my co-author Victoria Morgan-Smith.
Back in 2010 when Jez Humble and Dave Farley wrote their ground-breaking book Continuous Delivery, the Windows and .NET platforms lagged behind the Linux/Mac world in terms of automation capability. That is no longer the case – every core feature in Windows and .NET now has a PowerShell API and all the core tooling needed for Continuous Delivery – package management, artifact repositories, build servers, deployment pipelines tools, infrastructure automation, monitoring,and logging – are all now available natively on Windows/.NET.
Chris O’Dell (@ChrisAnnODell) and I decided we should explain how to make Continuous Delivery work with Windows and .NET, and thanks to the great editorial team at O’Reilly, we’ve published a short eBook:
The dedicated book website is at CDwithWindows.net and O’Reilly have published the first chapter of the book online as an article: Introduction to Continuous Delivery with Windows. We’d love your feedback: email@example.com
UPDATE: we’ll be at both PIPELINE Conference (March 23 2016) and WinOps Conference (May 24 2016) with printed copies of the book.
Note: we began writing the book in August 2015, and it’s astonishing (and exciting!) how much has changed in the 8 months since then, with Windows Nano, Azure and Windows support for Docker and containers, .NET Core, SQL Server on Linux, and even SSH for Windows. These and more recent developments do not feature in the book – perhaps we’ll do an updated version soon.
Summary: Pete Mounce (@petemounce) from Just Eat gave a compelling talk at the London Continuous Delivery meetup group on ‘team responsibilities in cloud-native operations’. I found the talk hugely engaging, with loads of detail applicable to many organisations. Here are my notes from the meetup.
I captured my notes as slides:
Update: the video of Pete’s talk is here on Vimeo:
There were several specific points made by Pete that were interesting for me:
The way we think about data and databases must adapt to fit with dynamic cloud infrastructure and Continuous Delivery. The need for rapid deployments and feedback from software changes combined with an increase in complexity of modern distributed systems and powerful new tooling are together driving significant changes to the way we design, build, and operate software systems. These changes require new ways of writing code, new team structures, and new ownership models for software systems, all of which in turn have implications for data and databases.
Read the full article on Simple Talk: Continuous Delivery for Databases: Microservices, Team Structures, and Conway’s Law.
(These slides were presented in a talk I gave at develop:BBC 2014 conference on 13th November in London)
I wrote an article recently for the Simple Talk website called Common database deployment blockers and Continuous Delivery headaches, where I outline some of the common problems preventing databases from being deployable – a major blocker to Continuous Delivery.
Deployability is now a first-class concern for databases, and there are several technical choices (conscious and accidental) which band together to block the deployability of databases. Can we improve database deployability and enable true Continuous Delivery for our software systems? Of course we can, but first we have to see the problems.
The recommendations include:
- Minimize changes in Production
- Reduce accidental complexity
- Archive, distinguish, and split data
- Name things transparently
- Source Business Intelligence from a data warehouse
- Value more highly the need for change
- Avoid Production-only tooling and config where possible [I mention this in my talk How to choose tools for DevOps and Continuous Delivery]
To address [these things] individually perhaps doesn’t seem too challenging, but to tackle deployability requires close, effective collaboration between developers, DBAs, and operations teams to achieve the right balance between rapid deployment and access to data.
Read the full article here: https://www.simple-talk.com/sql/database-administration/common-database-deployment-blockers-and-continuous-delivery-headaches/
I was interviewed recently by the folks at Ranger4 for their #DevOpsFriday5 question series. Since June 2014 (when I was interviewed) I have published a couple of things which expand on the original answers, so I have outlined these here. The questions were:
- What’s your preferred definition of DevOps?
- When people ‘do’ DevOps, what’s the most common mistake you see them make?
- How do you recommend an organisation new to DevOps start?
- What’s your prediction for what DevOps will look like in 2020?
- Where do you like to go to get a DevOps hit?
At the Unicom DevOps Summit event in London on February 28th 2014 we experimented with some extra audience/attendee participation by asking for questions on record cards and encouraged people to ‘dot-vote‘ on the questions most interesting to them. There were some good questions, but unfortunately we did not get chance to discuss many of them, so here are all the questions from the card board, along with some very brief attempts at answers.
- Should security be a part of DevOps?
- To what extent and how do you insist on standardisation for multiple Scrum + ‘DevOps’ teams with no separate Operations team?
- What’s the likely process flow of / disruptions to / duration of DevOps adoption?
- Where does ‘Operations’ sit in the ITIL model? All over the place? e.g. Service Transition?
- How about some example scenarios? Tangible comparison points would be useful.
- Where does DevOps start and finish (from a process perspective)?
- Is DevOps just a job title?
- Is co-location of resource necessary for successful DevOps?
- How essential is cloud technology to DevOps?
- How will the announcement that ThoughtWorks are ‘open sourcing’ their Go DevOps product affect other vendor products? Why pay for other products?
- There are a lot of open source DevOps/release/orchestration tools – is anyone using (or know about) the Windows equivalent?
- How do you overcome developer resistance to writing Run Book docs? Are the processes to drive adoption? Is it a sackable offence?