tombola careers
tombola careers


Blog | Tombola Careers

tombola blog
< back

Codegarden 2019

Posted by Ryan Coates
codegarden logo
I love my job! I got to go over to Denmark for Codegarden 2019 and got paid for the privilege! We flew out of Newcastle to London then pretty much back over Newcastle to Copenhagen. We then had to get a midnight train to Odense, well multiple trains as there was some work being done on the line. We arrived at the hotel at about 3am, exhausted by the travel but ready for an exciting few days at Codegarden.

Codegarden is like no other conference, we were greeted with high fives and entered a very friendly, happy and tech savvy community.

The conference was fantastic, a diverse set of talks, some very technical some very soft, there was loads of scope to get together with the community and share ideas. I got a huge amount out of the experience and thought it would be useful to document my key learnings in this blog.

There was a big focus on Umbraco v8 (we are on v7.6!), v8 being the new shiny version of Umbraco. The main focus of the release has been to tidy the codebase, anyone who has worked on the older codebases can see the massive value in that. They have reduced the number of projects and lines of code and use solid modern architecture principals lacking in previous releases, like dependency injection and having clear patterns used consistently.

They also added a few new features the only one of real note is Variants, essentially this allows you to have multiple languages for content, useful for an international business!

There was a big focus on extending Umbraco using packages, one of the really interesting packages is PreFlight, this lets you set content rules which are validated before content is published. You can define content rules which is massively powerful and a very interesting idea.

One thing that was very apparent from looking at all the amazing work the community is doing is that we don’t do open source very well. We have made some pretty amazing extensions to Umbraco that we could share with the community we could also benefit from all the amazing plugins and improvements that are being developed. Umbraco is really key to what we deliver, it accelerates our content delivery and has already made an incredible impact, we need to get more active with the community to gain even more benefits.

As a brand-new team lead I wanted to take advantage of some of the talks that had a bit of a softer focus, one very interesting talk was about teaching in technology. This is something I think we all struggle with, sharing knowledge is hard and creating a culture that is always striving to learn new things is a big challenge. A key takeaway was how we talk to each other, we often comment on how smart/clever/brilliant somebody is when they do something well this makes it harder for them to take risks least they fail and fall off the pedestal. Commenting on their effort and complimenting their hard work has a much better result. If we don’t challenge ourselves and take risks, we stagnate and don’t develop. The other takeaway was to be aware of your mindset, recognise fixed mindset behaviours and try to move towards a growth mindset. I’ll not copy and paste all these behaviours, I will however copy and paste a link.

Dotnet core was a big topic of the conference too, the Umbraco Core team are working hard on making the transition with minimal disruption. I hosted an open space session with the team to discuss their approach, we too are thinking about how we can move to Dotnet core and it was really reassuring to hear that they are using very similar approaches to what we are planning. We challenged each other’s ideas and I think we all came away with a better understanding of the road ahead of us.

Getting out of the office and listening to talks and sharing ideas is a great way to challenge yourself and think beyond the day to day development work that fills your week. It refreshes you, gives you great ideas and is a catalyst for innovation. We don’t need to go all the way to conferences to do this though, if we regularly step away from work and think and collaborate it will kickstart a flow of creativity and innovation. I know there are many of us that do this and benefit from it but many of us feel like we can’t step away from our work which is a cultural issue we can improve.

Another massive benefit was having a few beers with my colleagues in other teams, getting to know them and finding out about their challenges and joys within their teams was fun and useful.

read more

Continuous Disaster Recovery

Posted by Ryan Coates
Recently I’ve been fortunate enough to be working on a pretty widespread project. This has forced me to touch on many different technical aspects of the business to deliver and as a result could change the way we deliver in the future.

Recently I’ve been fortunate enough to be working on a pretty widespread project. This has forced me to touch on many different technical aspects of the business to deliver and as a result could change the way we deliver in the future.

It’s also allowed me to coin the CDR (Continuous Disaster Recovery) term, which is what I would like to talk about a bit.

I’m not going to bore you with all the technical details of the project but I think it’s worth giving a bit of a summary for the sake of context.

The project is (can projects ever really be in the past?) to deliver a usable Tombola CMS (Content management system) for all our international countries. Luckily for us other teams had been working tirelessly in making a robust and feature complete CMS server, so all we would need to do is drop it on a server and “poof” content managed? No, not at all.

We made some decisions early on that would need to be implemented to deliver the project.

  1. We would script our infrastructure using terraform
  2. We would ship our environment with our code using amis
  3. We would centralise application configuration

While these three design goals complicated the project to no end, and probably should have been isolated to separate projects, they did unlock some pretty cool options for deployments.

After loads of work we had scripted the infrastructure, were baking images and had all our configuration defined in the appropriate environment, all we needed now was a way to deploy and synchronize our CMS state between environments.

Our CMS wouldn’t really run like a traditional code pipeline, normally a developer/author makes changes then it is passed to various staging environments where it is tested and approved before going to live. The CMS would need to run differently, authors would make changes on the live site, have someone preview their changes and publish it. It would be instantly live and what this would mean is Live becomes our single source of truth which other environments would synchronize with.

Our CMS uses two places to store it’s state, s3 buckets are used to store images and media while a relational database is used to store the object representations of the pages.

So all we would need to do is restore the database from the source and copy all the s3 content across too, easy right? Well yes, actually it is.

#this script is used to take an existing snapshot for the cms instance, delete the existing db and restore it with the snapshot, it then adds dependencies missing from the snap shot
#finally the s3 buckets are synchronized

echo "deleting database"
delete_command="aws rds delete-db-instance --db-instance-identifier $db_instance --skip-final-snapshot"
eval $delete_command
echo "restoring from snapshot"
aws rds restore-db-instance-from-db-snapshot --db-instance-identifier $db_instance --db-snapshot-identifier $snapshot_name --db-subnet-group-name mysql_subnet_group
echo "waiting for db instance to become available"
wait_command="aws rds wait db-instance-available --db-instance-identifier $db_instance"
eval $wait_command
echo "adding security groups"
aws rds modify-db-instance --db-instance-identifier $db_instance --vpc-security-group-ids $vpc_security_group

#s3 bucket will need cross account sharing for this to work
echo "sync s3 buckets"
aws s3 sync $source_bucket $target_bucket
echo "All done!"

A simple bash script makes this all happen but there are a few caveats.

This assumes that a snapshot exists and has been shared with the environment you wish, also the snapshot needs to be copied which you can do like this:

aws rds copy-db-snapshot --source-db-snapshot-identifier shared-snapshot --target-db-snapshot-identifier local-snapshot

So you should have routine tasks, taking snapshots, sharing them and copying them.

You also need to make sure the script that runs this has delegated privileges to the source s3 bucket, like so:

"Sid": "umbracoRestoreS3SharedAccount",
"Principal": {"AWS": "accno"},
"Action": [
"Effect": "Allow",
"Resource": "arn:aws:s3:::source-bucket/*"

So now I can bring up a CMS stack with all of it’s dependencies, minimal security privileges and with a single script synchronize it with the live instance.

So why does this matter?

  • Well we can bring a fully synchronized environment up in minutes which means developers and authors can play around an experiment with the confidence that they can never break dev.
  • We can disable unneeded environments
  • We could even use this approach to facilitate testing, it could even support testing automation.
  • Finally it forces us to constantly test out and improve our DR strategy

It’s still early days for us working with this but the current trends in shipping environments with code, scripting infrastructure and cloud computing is giving us some fantastic opportunities which we will definitely be taking advantage of.

read more