Here we are again at the tail end of December, which means that it’s time for my end of year blog post.
For this edition, I wanted to take some time out to talk about some changes we’ve made to some of our internal systems over the past year, and the effects that they’ve had.
Moving to Slack
As a distributed company, our choice of collaboration / chat platform is incredibly important to us. Since the company’s inception we’ve been using an IRC server combined with multiple channels, which is something that has worked very well for us. However as time went on, we started to yearn for some of the features that Slack had to offer, and this year we took the plunge and shifted to Slack.
Our main concern about the move was keeping the “feel” that we’d built up over the years with IRC. Our chat platform has always helped bridge the gap to make sure that we didn’t feel isolated as remote workers, and the chat always had a certain type of feel to it. It has always had a good mix of work and non-work chat and conversations – it was really important not to lose that. Thankfully it remained intact with the move, allowing us to start using the benefits of Slack without losing our watercooler chat.
What are the main things we’re enjoying about Slack, I hear you ask. Good question.
Integrations, Integrations and More Integrations
We currently only have a few integrations, but they really do help make Slack a more productive place.
The key ones are:
- Visual Studio Team Services, for build notifications
- Octopus Deploy, for deploy notifications (I’ll talk more about Octopus deploy later)
- Raygun.io, for errors
- Support mailbox monitoring, a quick tool we wrote to keep an eye on our shared support inboxes and to notify the team when a message arrives
Offline Access and Notifications
IRC requires you to be connected in order to see the channel chat, so anyone who doesn’t leave their PC running 24/7 can potentially miss certain conversations. This is something that can obviously happen quite a lot when you have team members in different time zones.
With Slack it’s much easier to flick through channel history and see what you’ve missed, especially with good use of @ mentions to draw attention to important messages.
Shared Customer Channels
We currently have a couple of channels which we share with customers, and this is something we’re looking to do more and more in future. It doesn’t suit every relationship, but when it’s a match is can work really well. Watching collaboration between multiple parties (us, the design team, and the customer) in real time is a fairly wonderful thing to behold.
Our Issues and Considerations
I’ve already mentioned the concern about keeping the right “feel” for our chat, but in addition to that we had a couple of other concerns with Slack.
Firstly, I got a little bit caught up trying to think of what the ‘perfect’ channel structure would be. How many channels should we have? Where should the integrations go? Do we need a naming convention? It might sound like a silly thing to obsess over, however it can have a large effect on everyone’s day to day life, and therefore on their sanity.
Without going into too much detail, here’s a quick overview of what we’re using at the moment.
We have a single “chat” channel, which is private and limited to the team only (because we have customers accessing our server). We left #general as it is (open to all) but we don’t use it. We have all integrations going into their own channel, however in future this might change (because in some cases we might want our customers to be able to see integrations specific to their applications). We have dedicated channels for our main projects, and then a generic ‘other projects’ channel which can be used as required for smaller or short term projects which don’t justify having their own permanent channel. We’ve prefixed all customer channels with the “customer-“ prefix, which means they’re all grouped together to avoid the risk of someone accidentally spamming something in the wrong channel. The last point might sound like a small thing, but it really does help reduce cognitive load.
We also had concerns about data retention. When we ran our own IRC server we knew what was happening to the data – but with Slack, it’s all out of our control (remember folks, there is no cloud – it’s just someone else’s computer!). Really there isn’t much we can do about this, other than purchase a plan which allows us to set customised data retention levels for certain channels.
Finally, we’d built a couple of bots for IRC which we needed to say goodbye to. Our ‘ScrumBot’ ran our daily standups, but in addition he also had a large amount of custom functionality that had been built strictly ‘for the lols’. Specifically, he had a database of year’s of chat and would randomly talk to us using Markov chains plus the database to construct some words of wisdom. The output was mostly gibberish, but it was amusing gibberish. For our daily standups we’re currently using Geekbot (which is good, but could use a few more configuration options), and when we get time we may get around to porting ScrumBot over to Slack.
Octopus Deploy (and VSTS)
Everyone loves deployments. They’re so much fun and… yeah, nah. This year we finally took the plunge into the world of better devops and one click deployments. It’s something we’d been putting off for a while, and it feels really good to have done it – the benefits are clear and noticeable.
However, Octopus isn’t cheap, both in terms of the annual cost, but also in terms of the time required to get it setup. It has taken us quite a bit of time to get things working in all our environments, and there’s still a few discussions to be had about choosing the best way for us to configure things.
There’s a lot that we could write about Octopus which is best saved for future posts, so without going into too much detail here’s a few of my comments and observations in hindsight.
Getting the balance of planning right is difficult. I recommend just jumping in and getting things underway, but at the same time being prepared to go back and change things if they’re not working for you. Planning is great, but what looks good on paper might not work in reality.
Transforms or variables? Octopus allows you to use variables against sites, and the way it allows you to flag certain variables as ‘sensitive’ is very handy. However if you’re not careful you can end up with a lot of variables very quickly. If you’re already using transforms then it may make sense to continue doing so, or you may want to shift everything into Octopus variables. The ‘right’ setup is going to be different for everyone and it’s not going to be clear what’s best for you until you’ve got a few sites setup so be prepared to try different things and adapt based on what feels right.
Differing levels of security in customer environments can complicate matters. For example, servers that live behind VPNs and so on. Octopus has ways of handling this of course, however be prepared for some sites to be more complicated to setup than others and make sure you start with some of the simple ones.
My main observation is that getting everything setup will take time. Octopus is pretty easy to use, and the work required isn’t complicated, but it still takes a lot of time adjusting and fine tuning to get things just right. Be prepared for that, and factor it in to any costings.
We’re still migrating a few of the smaller sites over to Octopus as and when we work on them, but have moved most of the sites we work on most often over, and you very quickly feel the productivity benefits – especially when it’s combined with Slack integration!
VSTS vs SVN
Part of what made our shift to Octopus easier was that we’ve been moving away from Subversion over the past year, and have been shifting everything over to Visual Studio Team Services (or whatever it’s called this week – I’m honestly losing track). This has meant one less box to maintain (as we ran our own SVN server), one less VS plugin to have installed (bye bye VisualSVN – you were great while we needed you!), that our internal systems were more in line with those of our customers, and finally that we could use the build capabilities of VSTS to work well with Octopus.
This year we’ve worked more and more with Umbraco. We’re still using the Site Foundation Framework for sites when it makes sense, however more often than not we’re trying to use Umbraco when we can. Tracey has been doing some really neat things with Umbraco, specifically in the areas of making the customer editing experience as streamlined as possible. Umbraco is continuing to grow as a CMS platform, and we’ve really enjoyed using it this year and look forward to making many more sites with it in future.
Signing off for 2016
This year has been a challenging but rewarding one. A huge thanks goes out to all of our customers and partners for helping make this year great. We’re looking forward to a break so that we can come back refreshed and revitalized in 2017.
The Ignition Development office will close at 1700 on Thursday the 22nd December, and will be reopening at 0900 on Monday 8th January. Please note that emails to your usual consultant may go unanswered during this period. If you have any urgent issues or support requests during that time then it is imperative that you email firstname.lastname@example.org for assistance. One of the team will be on hand to help and using our support email address will ensure they get your message.
From all of us here at Team Ignition we wish you a Merry Christmas, and we look forward to speaking to you next year.