Like most relationships, we got to know each other a little better and the prolific displays of our affection for each other started to feign. We’re still “going steady” but it’s complicated. With the benefit of experience, we’re now one of those couples that look down on young love in an “if only you knew kind of way”.

Getting Started

Like most things in software engineering, Docker began with setting up the dev environment. By the time we started to explore using Docker we already had several python services running in production plus our main product.

We made the decision to start slow, slowly moving services over to Docker one at a time so we didn’t cause too much upheaval for the rest of the team. Before long we had everything running in dev without any issues. This replaced a really horrible Vagrant+SaltStack setup that would work eventually given that you ran it enough times. This was a major improvement. We had something that worked first time, worked everywhere and was much easier to use. +1 for immutable infrastructure.

Launching the first service 

Following our ethos of “measure twice, cut once” we picked a fairly low impact service as the first thing to migrate over to Docker in production. We mentioned in our last post on docker that one of the things that had prompted our decision to jump on the proverbial bandwagon was the release of Docker Swarm.

We did not have a good time with Swarm at all. We experienced significant stability issues from the start. We were experiencing lots of issues with the overlay network suddenly not working. Services would stop being able to talk to each other meaning that the whole cluster would eventually end up out of sync. Its ability to recover from these issues was also non-existent. This was our first bust up! We cried, we ate chocolate and we hugged our mums. Eventually we decided to make up and give things another try.

It wouldn’t be fair to say that it was entirely Docker Swarm’s fault. We were almost certainly doing something wrong somewhere. The main issue was that Docker Swarm was new and the usual ways of solving obscure problems like the ones we were having were offering little support. We agreed that we needed something a bit more mature.

I need a man, not a boy…

We quickly drew up a short list of options that offered a more mature way of running and managing Docker. We felt that using a managed service that would do all the complicated stuff for us was a better idea. We wanted to focus on the things Docker would enable us to do rather than managing Docker itself.

Two clear options presented themselves. AWS ECS (Elastic Container Service) and Google Cloud (GKE). ECS is essentially a proprietary Amazon orchestration tool on top of EC2. Google’s GCE offers hosted Kubernates. Both services were very competitive in terms of features. HA (high availability) auto-scaling, self-healing and easy deployments are included with both. As we were already running our infrastructure on AWS it seemed using ECS was a no brainer.

Amazon ECS 

Amazon suggests using Elastic Load Balancers for your clusters service discovery. ECS makes use of the ELB’s health check for failing over services when new versions are deployed. At the time, AWS still didn’t allow you to route requests based on hostnames with ELBs. This would mean that we would need an ELB per service and they are not cheap. We decided that we would look at other ways to manage service discovery across the clusters in favour of keeping the costs down. This decision wasn’t easy to make given our desire to have a service deal with all the complex stuff for us.

After a bit of searching, we settled on using Nginx + Consul + Consul Template to manage service discovery across the cluster. Consul acts as a service within the cluster. Consul can be asked questions about the state of clusters. As services are added or updated, Consul will itself update to keep a track of those changes. Consul template is responsible for re-writing the configs pointing to services as Consul updates. In our case this was the upstream proxies in Nginx.

We had to play around with various strategies to manage failover to new versions of services with Consul. Simply updating the service every time we deployed would mean that the ELB’s might still route to old tasks that were being drained as new ones were launching. After plenty of trial and error, we essentially ended up with a “roll your own” version of what the ELB’s were offering. Failover was not the only thing we spent plenty of time working on. If you take anything away from this post make it this. Memory allocation is everything on Amazon ECS.

Just as our deployments felt solid and the stability of the cluster had settled Amazon announced they had launched support for hostname routing with ELBs as well as the ability to route based on specific paths. We’re stoked that Amazon has finally shipped this much needed feature (even if it is four months later than we would have liked). So what does this mean? We can now have a single ELB that is capable of routing to all of our services. We think this is going to provide us with more stability and also allow us to just let Amazon do the hard work.

Using ECS over our existing infrastructure has also resulted in a 50% cost saving too. We previously had instances for each of our environments. Docker containers have allowed us to run various configurations of the services on the same host. Happy engineers + Happy wallets = a ton of awesome!

In conclusion

We’re still in love with Docker . We’ve learnt a huge amount transitioning our services to run inside containers. The time saved launching new services into production in contrast to what we had with salt cannot be measured. It’s enabled everyone in our team to work more closely with the infrastructure and getting new team members set up is super quick and extremely reliable.

We’ve got an exciting list of improvements to the way we deploy planned that are sure to make us even happier with our choice to use Docker.

The post Relationship status: It’s complicated — Getting Docker into Production appeared first on .

Steve has over 25 years’ experience in sales leadership roles, managing and building enterprise sales, growing customer bases and developing strategic partner alliances. At companies such as SAP, Ariba, iPipeline and i2 Technologies he has implemented and executed transformational growth plans, improved and institutionalised the sales engagement process and refined the solution positioning and value propositions. Steve has a wealth of experience in partnering, selling and delivering high-value enterprise solutions to global customers.

Steve will be working closely with the sales and marketing team at Old St Labs to build on recent successes and create a repeatable sales process that will match our business’s ambitious growth plans.

Speaking on Steve’s appointment Old St Labs CEO Mark Perera said;

“Having Steve join as an advisor is a huge coup for Old St Labs. The experience he brings in optimising sales activity, process and growth in our space is second to none. We’ve had some great early success as a business but it’s critical that we build a repeatable, scalable model for optimising our sales process and lift our business to new level. Steve is perfectly placed to help us deliver on this.”

Steve had the following say on joining the Old St Labs team;

“It’s exciting to be joining such a young innovative organisation at this point in its expansion. Old St Labs has already experienced some significant wins particularly with the recent announcement of the Vodafone account and I’m looking forward to the challenge of working with the team to drive sales and optimise the growth engine.”

Stayed tuned to our blog for more news on the growth of our business.

The post The Next Level of Growth – Steve Canning Joins Old St Labs. appeared first on .

Vodafone recognises that many future innovations in the telecoms space will flow from an organisation’s extended value chain and supplier collaboration is the most effective way of ensuring these innovations are quickly and seamlessly integrated into the business.

Vodafone is deploying Vizibl, the leading supplier collaboration tool developed by Old St Labs, to manage its proof of concept testing and supplier innovation with some strategic and new suppliers.

Vizibl is a shared software platform that creates an environment where businesses and their suppliers can work together in productive collaboration. Through project tracking and advanced reporting, Vizibl empowers businesses and their suppliers to make smarter decisions that deliver measurable outcomes.

By connecting organisations to their supply base and facilitating collaboration, Vizibl provides clarity into supplier relationships and ensures suppliers are fully aligned with and are working towards company objectives.

Ninian Wilson, CEO Vodafone Procurement Company, said: “Supplier collaboration and innovation is key for us at Vodafone, but the complexity of these projects can make them a challenge to manage. Old St Labs and its platform Vizibl will give us a centrally managed platform that helps us to provide the structure and reporting tools needed for key proof of concept and supplier innovation projects to flourish.”

Mark Perera CEO and Co-Founder at Old St Labs added: “It is becoming more and more apparent that suppliers hold the key to business success and that effective collaboration is required for organisations to leverage that source of innovation.”

“We are thrilled to be working with an industry leader like Vodafone to provide them with the tools to manage the ground-breaking projects they are embarking on. Vizibl is all about creating clarity and an environment in which buyers and suppliers can work together in collaboration. Vodafone is getting out ahead of the curve with these initiatives and we’re delighted to be out there with them.”

Old St Labs is experiencing rapid growth and works with a number of top global companies in other industries such as leisure and telecoms.

The post Old St Labs partner with Vodafone to drive ambitious supplier collaboration and innovation agenda appeared first on .

Mark Perera, CEO and Founder of Old St Labs, had the following to say “This is a fantastic step forward for us as a business. h&z is one of the premier consultancies out there and it’s in depth knowledge of SRM is a huge asset to us. We will work in partnership with each other to help our clients drive a real return on relationships. Having worked closely with h&z before I am incredibly excited by what the future holds.”

Klaus Katzer, a partner at h&z Business Consulting, had the following to say “Its fantastic to see our two businesses come together. Vizibl is the technology that will support the great work we’re doing in the supplier collaboration and management space. I feel it’s our joint passion and drive to modernise procurement and supply chain management that has brought us together. Both businesses are well recognised for their philosophies when it comes to value creation with SRM being one of the key drivers”

Through its product Vizibl, Old St Labs is on course to disrupt an entire market and change the way businesses engage and work together. h&z will be a key partner in driving the change management and training required to deliver on this lofty ambition. This move further enhances h&z’s strategic position as a provider of ‘business excellence’ and increases Vizibl’s market reach.

About h&z business consulting AG

With locations in Munich, Düsseldorf, Dubai, Hamburg, Paris, Vienna and Zürich, h&z is one of Europe’s leading consultancies for business transformation with an emphasis on purchasing and supply chain, product innovation, sales and service, and training. Large corporate groups and well-known midsize firms in all industries have been trusting the expertise and experience of h&z for 20 years. With the motto “Consulting with Head, Heart, and Hand,” our consultants develop innovative solutions and implement them consistently. As a member of the Transformation Alliance, h&z belongs to a worldwide network of over 400 consultants.

For further information, please visit www.huz.de.

About Old Street Labs

Old St Labs is fanatical about making business easier. The company’s products increase innovation, collaboration, alignment and agility between you and the businesses you work with. By combining immense processing power with elegant functional design, Old St Labs is changing the face of enterprise software.

About Vizibl

Vizibl is the first enterprise tool that brings businesses and their suppliers onto the same platform. By setting bold objectives and providing the governance and infrastructure to deliver on these aspirational goals, Vizibl lights the path for successful supplier collaboration. Vizibl shifts the focus away from cost savings and delivers outcomes that drive tangible business value. With Vizibl, relationships undergo a transformation from combative to collaborative, enabling businesses to maximise their ‘Return on Relationship”.

The post Old St Labs and h&z announce partnership appeared first on .

Rob joins Old St Labs from Oracle where he held the position of Global Director, Adoption & Transformation Services of the Oracle Marketing Cloud, a role that saw Rob oversee 100s of clients and delivering millions of dollars in SaaS renewal and expansion revenue.  He was proudly supported by a global and senior team of technical and digital marketing professionals focused on helping customers adopt and adapt Oracle’s Marketing Cloud technologies.

In his new role as VP of Account Management and Strategy, Rob will focus on building and leading a team of account managers that will principally support our enterprise accounts in their adoption and use of the Vizibl platform. As part of the OSL leadership team, Rob and his team will work closely with Maxi Glas, VP Customer Success in scaling our ability to serve and delight our fast-growing customer base.

Speaking on Rob’s appointment, Old St Labs founder Mark Perera had the following to say:

“Getting Rob onboard is a real game changer at this point in our development. Our customers and their success is our first priority and are our key lever to disrupting the way businesses interact with their suppliers. We’re witnessing complex global enterprises in traditional industries like Life-sciences/Pharma and Hospitality make quick use and adoption of our platform, Vizibl.  They have a ferocious appetite to accelerate those early successes and propel themselves to the next level of supplier relationships. Rob brings the perfect mix of pragmatic technical experiences, customer success strategy and proven success programs that scale, as well as a keen commercial account management acumen to give our customers the trust and certainty to grow their use of our platform, Vizibl and ultimately expand beyond their initial investment.”

No stranger to the fast paced and challenging world of Enterprise SaaS software, Rob echoed Mark’s excitement saying:  

“I’m thrilled to join the Old Street Labs leadership team and to add another dimension to the Vizibl customer success organisation.  We are at such a critical stage in our growth and development as a leading SaaS provider, innovator and disruptor.  The customers I’ve met all extol how much they love working with the OSL team and using Vizibl to simplify the complex job of managing business critical business challenges and the relationships that underpin their supply chains.  It’s a real privilege on the first day to work with world class private and FTSE 100 brands and help them attribute new value creation beyond savings.  And to give them the support and encouragement to drive up the relevance, return and professionalism of procurement and supplier relationship management.”

Rob is the 16th new starter Old St Labs have brought onboard over the course of the last 12 months reflecting a period of significant growth for the organisation.

About Old St Labs.
Old St Labs is fanatical about making business easier. The company’s products increase innovation, collaboration, alignment and agility between you and the businesses you work with. By combining immense processing power with elegant functional design, Old St Labs are changing the face of enterprise software.

About Vizibl
Vizibl is the first enterprise tool that brings businesses and their suppliers onto the same platform. By setting bold objectives and providing the governance and infrastructure to deliver on these aspirational goals, Vizibl lights the path for successful supplier collaboration. Vizibl shifts the focus away from cost savings and delivers outcomes that drive tangible business value. With Vizibl, relationships undergo a transformation from combative to collaborative, enabling businesses to maximise their ‘Return on Relationship”.

The post Building Momentum – Rob Heerdegen Joins Old St Labs. appeared first on .

William attended Stanford University, where he earned master’s degrees in electrical engineering and management science. After designing integrated circuits for Linear Technology and a stint in finance, he led the implementation program at HP Autonomy’s Digital Safe.  Most recently, he worked as a Customer Success Architect (CSA) at DocuSign and moved to London to open their EMEA CSA practice.  

Old St Labs Founder, Mark Perera, said the following on Willian joining the team; “We’re thrilled to have William on board, his experience at HP and more recently DocuSign translates directly to what we’re trying achieve in the customer success space at Old St Labs. I’m certain William will be an asset to our business.”

William is the 15th new hire Old St Labs has made in the last 12 months which represents a more than doubling of the team. This hire further positions the business for success in the areas of product implementation and customer success, both of which are critical for the continued growth of the company.

On joining the business, William had the following to say; “I believe Old St Labs is poised for success. The company has a great product suite that solves a problem every large organisation faces. Leading businesses know that supplier collaboration is a sure-fire way to avoid being left behind by industry disruption and I look forward to working alongside them to overcome that challenge.”

Speaking German, Spanish, some French and a little Japanese, William doubles as the Old St Labs polyglot. William lives in Hampstead with his wife Caroline and 9-month old son Samuel.

The post Next Level Customer Success – William Poucher Joins Old St Labs appeared first on .

As well as founding Coupa, who successfully IPO’ed in October (prompting me to question if procurement software had finally become sexy), Noah has deep experience in the enterprise technology space having held leadership positions at both Oracle and Amazon.

Noah will be working closely with our product and marketing teams to ensure our products perfectly fit the needs of our market and that we are able to explain the benefits and value our products deliver in a elegant, engaging and pragmatic manner.

Speaking on Noah’s appointment Old St Labs CEO Mark Perera said; “We are thrilled to have Noah onboard. Noah is a visionary technologist in the enterprise Software-as-a-Service space and his success with Amazon Web Services, Oracle and in founding and growing Coupa Software from an idea into the number one e-procurement solution in the world speaks for itself.”

“Old St Labs has a bold vision to radically change the way businesses interact with their suppliers” Eisner said. “Many in the procurement sector lack visibility over their supplier relationships and the key to innovation both now, and in the future, is better management of these relationships. This will give businesses the agility and competitive advantage they need. I’m excited to be working with a company that understands the issues the sector faces and I’m thrilled to be joining Old St Labs at this point in their journey.”

We are thrilled to have Noah onboard and working with us he is a huge asset to our business and with our San Francisco office now open he’s also our new neighbour.

Welcome onboard Noah!

Background to Noah Eisner

• Eisner co-founded Coupa Software and grew the company from initial concept to 100’s of customers.
• Eisner previously held the position of as a General Manager at Amazon Web Services. In this role he was responsible for business planning, product and engineering efforts for the business. Additionally, he lead the opening of AWS’s development center in Palo Alto and grew the organization to over 200 engineers.
• Prior to founding Coupa and his time with Amazon, Eisner held the role of Senior Director of Product Management at Oracle. In this position Eisner lead a 25+ person product management team in charge of major Oracle applications, including iProcurement, Purchasing, Services Procurement, iSupplier Portal and the Supplier Network.
• Eisner holds a BS in Operations Research / Industrial Engineering from Cornell University and an MS in Industrial Engineering from Stanford University.

The post Coupa Founder Joins Old St Labs appeared first on .

Gamification is the concept of applying game mechanics and game design techniques to engage and motivate people to achieve their goals. This mechanism is extremely powerful and is transforming business models by creating new ways to extend relationships, craft longer-term engagement, and drive customer / employee loyalty.

The root cause of this success is a powerful psychological mechanism that taps into a basic desire that exists sub-consciously within us all – a desire for status, achievement and reward. A lot of people will read that sentence and picture a narcissistic egomaniac that doesn’t resemble them whatsoever, but this exists at a much smaller level and we are all driven in one way or another by these factors: whether it be something superficial like a new car or something more meaningful like recognition from colleagues. 

Don’t feel guilty about it though, this mindset is ingrained in us by society for our entire lives: as a baby you receive praise from your parents (reward) for desirable behaviour such as speaking (achievement). As a child you are considered “cool” (status) for being good at sport (achievement) and therefore other children want to be your friend (reward). As an adult you are given a promotion (status) for performing well at work (achievement) and therefore you get a higher salary (reward).Those are only a few examples, and when you consider much of our daily life is based around this same cognitive loop it is no wonder that it can influence us so much when integrated into user experience.

This is why gamification is invaluable to us, by integrating these factors into the Vizibl user experience we can create more powerful engagement that will drive the value of the software considerably. With higher engagement we get more tasks, events, discussions and reviews being created, this naturally means more visibility across the company and more importantly – Value Beyond Savings.

How Have We Gamified Vizibl Then?

The first problem we encountered in this is that Vizibl is not a game – “Vizibl is the online platform that gives your team a single place to manage all your commercial relationships.” Doesn’t exactly sound like something that can be gamified, we’ll leave that to the consumer apps like Tinder, Candy Crush and Instagram. This is the wrong mindset, these apps are the masters of gamification and have driven millions of users to addiction through the effective use of gamification. There are thousands of dating apps but Tinder has taken the market share from all of them with over 1.4 billion swipes daily, similarly there were thousands of photo sharing apps but Instagram is the one with 500 million active users, Candy Crush is no new concept but people waste hours playing every day – these successes are because the user experience is so perfectly gamified. Not only do these apps show the value of gamification to us, but they also have helped to inspire many of the gamified features that are on the Vizibl platform already. It is through applying these concepts to our platform we have managed to incorporate many gamified features into the Vizibl user experience and we have many more in the roadmap still to come.

Lesson 1: Always have a notification

LinkedIn and Facebook are the kings of this. Whenever I log into these sites there is always a notification, even if the notification is that it’s Oswald Copplebot’s birthday or that Dave Bailey (who I have never met) has a new job, it doesn’t matter – I still get a little bit of excitement when I see the little red notification icon.

We have applied this to Vizibl by creating a more eye-catching notifications icon in order to generate more excitement for the user. As well as this we have a smart notifications feature in the roadmap for Q4 that will have more engaging notification language, more relevant notification criteria, daily email updates (optional of course) and integrated reminders. All of these should keep users coming back to the platform engaging at a higher level than before.

Lesson 2: Operant Conditioning

B.F. Skinner’s principles don’t just apply to pigeons, rats and cats, they also work on humans and can be integrated into user experience! When you complete a level on a game you get a trophy or a badge to say well done! Even though this is immaterial and just some pixels on the screen it still makes you feel good about the fact that you completed the level and makes you want to continue to play so you can earn another.

We have applied this to Vizibl by incorporating a new checklist of tasks to complete on the homepage, once checked as complete a positive message pops up to congratulate the user for completing the task. Even though this is a small feature it will still make the user feel more productive and increase the likelihood of them engaging with the platform.

Lesson 3: My score is bigger than yours

Us humans are very competitive, and when we’re winning we want people to know! Almost all games have some sort of scoring incorporated into the user experience, this allows people to compare themselves to others and therefore drives competitiveness as they strive to achieve the highest score. If you are unfortunate enough to have experienced flappy bird then you will know the power of this competitive drive!

We have applied this to Vizibl by starting work on a value tracker feature which will allow us to assign value scores to projects in Vizibl. This will allow projects to be objectively compared and will drive value from the Vizibl platform as teams strive to meet targets and continue to improve on past value scores.

Lesson 4: Getting personal

Almost all games nowadays allow you to customise your character, with some games taking it as far as choosing what brand of underwear they wear. Now underwear might not be the key to driving further engagement but the customisation concept still applies. By allowing a more personal user experience the player has more attachment to the character and is more likely to come back to the game to improve and advance their character.

We have applied this to Vizibl by handing the profile personalisation over to the user. We have seamlessly integrated the input of personal details such as job title and profile picture into the sign up process in a brand new onboarding flow. With users now inputting personal details into their account they are more likely to engage as they begin to take pride in their account and the content that they input onto the Vizibl platform from it, thus generating more valuable content for their supplier relationships.

Final Thoughts

At the end of the day Vizibl is not a game, meaning gamification is not the be all and end all of the success of our product. However it is clear to see that by integrating gamification effectively into our user experience we have managed to, and will continue to, drive higher engagement with the app and therefore value beyond savings.

The post Gamification and Vizibl appeared first on .

We aren’t fans of those types of statements but we’ve recently started to explore what Docker can do for us. The recent introduction of Docker swarm mode really got us excited. We decided to port one of our less critical services to docker to see what all the fuss is about. Here’s some of our favourite things so far.

1. Dockerfiles

Dockerfiles are one of my favourite things about Docker. We’ve been usingSaltstack for a while Old St Labs to manage our infrastructure. Over time it’s become a real P.I.T.A to manage.

When using tools like Salt I always felt it would be easier to write a bash script and deal with all the hate from my peers. Being able to open up a Dockerfile and add some bash commands via RUN statements is a great thing.

FROM python:3.5.2

WORKDIR /opt/code

ADD . /opt/code/

RUN python /opt/code/setup.py develop

EXPOSE 8080

CMD ["python", "example/app.py", "-p 8000"

The Dockerfile above provides us with a working container capable of serving requests from our python app. In 6 lines of code.

Dockerfiles == happy engineers.

2. Swarm Mode

Swarm mode was recently released as part of Docker 1.12. This release brought about the changes we had been waiting for. Orchestration of containers over many hosts, until swarm mode was introduced, was a challenge. There were a few options available like Consul and Kubernetes. I’ll admit we never gave any of those a shot as they all seemed complicated for our use cases.

Docker’s new command docker service is how the swarm and it’s containers are managed. The elegancy of it’s simplicity is just a joy to work with. It exposes all the similar APIs we’re used to when working with docker on a single host. Except now we can manage tasks running across many hosts using single commands.

Here’s an example of launching a new Nginx service into the swarm and then updating it to expose an extra port.

docker service create --name nginx --network front-tier 
--replicas 2 nginx:latest

docker service update --publish-add 80:80 nginx

Even rolling out a new version of Nginx is completely trivial.

docker service update --image nginx:1.11.3-apline nginx

Swarm mode comes with an internal DNS server that is capable of round robin lookups across hosts. It’s built on top of IPVS. This means a request on port 80 made to any node in the cluster will route seamlessly to any of the available Nginx containers in the swarm.

We can’t begin to describe how much this pattern of launching services has improved our existing dev operations.

Swarm mode == happy engineers.

3. Docker Compose

When I first encountered docker-compose it was a separate project called Fig. Fig, much like Docker at the time, felt a little unstable and lacked all the features I wanted. I’m pleased to say that’s no longer the case.

Docker compose is now an integral part of the Docker eco-system. Users are able to describe their services and the dependancies between them using a .docker-compose.yml file. It supports all the features Docker has to offer including the recently released swarm mode.

version: '2'
services:
  web:
    build: .
    ports:
     - "5000:5000"
    volumes:
     - .:/code
    depends_on:
     - redis
  redis:
    image: redis

Running docker-compose up will build a container, pull any missing images and run the service. Being able to ship this around with your source code makes on-boarding new engineers to a project a piece of cake. We’re even using it to spin up the app for test runs on GitLab.

Being able to iterate quickly when writing software, I believe, is important. Adding a new version of Postgres or adding redis into the stack with docker-compose couldn’t be any simpler. We would have had 4 times the amount of code to have this working in salt.

Docker-compose == happy engineers.

4. Docker for OSX

I could put this as item 1,2,3,4 and 5! Docker for OSX shipped recently and has transformed the experience of using docker on a mac.

I had been using boot2docker for a while and had issues on and off. I think it was a great attempt to bring docker to OSX but it was pretty ambitious. The delicate balance of versions and networking required to use boot2docker was frustrating at best.

We are using Vagrant with a salt provisioner for our development environment. We have the local docker service talking to the Vagrant vm’s and vice versa with no problems. The simplicity of spinning up a clean dev environment is such that it prompted me to start new projects. That can’t be a bad thing (project pending of course)

Docker for OSX == happy engineers.

5. Immutable infrastructure

Last but not least is the concept of immutability. If you’ve read anything about Docker you’ll know that it’s greatest strength is immutability. The fact that you have the same container, running the same code anywhere is amazing.

We plan to take advantage of this to help us scale our QA and deployment processes. We hope to do away with siloed environments and have containers move all the way through testing to production. We hope to share more about that in the future.

Immutable Infrastructure == happy engineers.

Wrapping up.

We’re taking small steps with our move to Docker, migrating one service at a time. We’ve started with some of the more light weight services to ease the transition but so far we couldn’t be happier.

We’re always looking for ways to optimise all parts of system. From SQL performance tweaks to cutting down the time an engineer spends managing our infrastructure. Anywhere we can hand time back to our engineers to work on “the cool stuff” is always a no brainer for our team.

If you want to be a happier engineer and like the sound of what we’re up to, come join us, we’re hiring.

The post The Best Things About Docker (so far) appeared first on .

Testing is often an overlooked part of development. It is time consuming, tedious, and the philosophy is not always easy to grasp, so it’s often left out of the development process.

But programming without testing is a sure recipe for trouble down the line. The minutes spent testing today will be hours saved tomorrow.

It is not excessive to say that we spend one third of our time writing tests.

Without it, we would spend an unreasonable amount of time debugging our app by hand.

The way we do it

We like Behaviour Driven Development (BDD) and Test Driven Development (TDD). We try to write tests before we start programming, as much as possible.

Between the moment we approve a feature and the moment we release it, the code will go through this process:

1. Acceptance testing
2. Unit tests
3. Code review
4. Visual regression tests
5. Manual testing
6. Smoke tests

Acceptance testing

When we start working on a feature, we start writing user stories. They describe the functionalities of the feature in simple steps.

We use Angular to build Vizibl, and there is an amazing tool to run Acceptance Tests against it. It’s called Cucumber, and it allows us to translate Gherkin syntax into Protractor tests.

This system allows us to write easy to understand scenarios as we go through the design and plan the sprint. Each action can be re-used by the QA team without the dev team having to write more tests.

These scenarios will all fail at first, then start to pass as we release parts of the feature. The team can release the feature once all the scenarios pass.

While we write these tests at the start, we run and adapt them as we release parts of the feature.

Unit testing

Once the team has agreed to all the acceptance criterias, the actual development starts. As mentioned before, we use Angular to build our application. Each angular component, filter or service must have its set of unit tests.

The developers are in charge of writing the unit tests. The QA team is not involved in that process.

Each merge request is peer reviewed, and test coverage is an important factor of quality. Don’t expect to get away with lousy tests just because QA isn’t looking at them!

We use Jasmine to write unit tests and Karma to run them. We also use a mocha reporter because it’s prettier, and around here we like what is pretty. Although there has been discussions about using the Nyan cat reporter…

Code review

As mentioned before, a co-worker will review every bit of code, and will decide if it is good enough to merge or not. What does good enough mean? Enough tests, easy to understand algorithms, no forgotten console logs… Well.. Clean code, basically.

This is the main reason why you should bring snacks to the office every now and then. You may notice your pull requests getting merged much faster…

“If it’s not tested, it doesn’t work.”

Visual regression testing

As our app continues to grow, it becomes almost impossible to know that the CSS you just wrote didn’t break something else. This is where regression testing becomes your best friend.

We tried every possible solution we could find but none was good enough. So we decided to build our own solution, called LeRegression.

LeRegression works in several steps. It takes screenshots of your app, then compares them to a reference (the master branch). It then displays the results and shows you where there has been regressions. It can be hooked to github, and to any CI environment. For faster results we use the computing power of Browserstack to browse our app.

This tool has been a lifesaver many times and saved us countless hours of manual testing. And even with 10/10 vision in both eyes, you always miss something!

Manual testing

Because if you want something done you need to do it yourself, we do have a step involving manual testing. Our QA team will often make you grunt and swear, finding every last issue that may have slipped through the net. But we love them for it, and they may even be the most important part of all our testing process.

Manual testing is also a continuous process. The QA team is not just responsible of finding issues and reporting them. It is their responsibility to verify that new features are well implemented.

They ensure that developers fixed bugs and didn’t break anything else. They keep performing exploratory testing tasks to discover hidden issues. More importantly they guarantee that we deliver everything to the high standards.

In the end, we’re programming for humans, not machines.

Smoke testing

The very last step, the last little check to make sure everything looks fine. While manual QA of the feature in development is thorough, the smoke test is a quick overview of the product. It allows us to make sure that no major functionality broke somewhere else on our app.

You know, just to sleep on both ears.

That’s all folks!

This is not an exhaustive list of all the possible tests that a team can put in place in their development process. But it’s what we do. It ensures quality and stability as we release more and more features.

As we keep growing, we’ll add more steps to our release process. The next one may be a code analysis tool. And then who knows, stress tests? Soak tests? The sky’s the limit!

Because at Old St Labs, again, we care about quality. And if you do too, you should join us.

The post How we Approach Testing at Old St Labs appeared first on .