Tag Archives: Continuous Delivery

Security Test-Driven Development – Spreading the STDD-virus

Posted on by

Agile development with short release cycles have been here for a while now. Most of us want fast feedback loops and many even Continuous Delivery with changes in production software everyday. However, most of us also want secure software and the question is: Can security engineering keep up the pace? A fast feedback that your production website has been hacked is not so nice.

Security is a quality attribute of your software, just like performance. If you don’t want to be surprised by bad performance in production, what do you do? You test and design for it of course and you preferably do so continuously from the start.

In my experience, the same however cannot be said of security. It is very often relegated to a once a year penetration-test activity. Not really an agile way of working is it? Not a secure one either since untested software is released as often as everyday. There must be a better way of working which allows us to both work in an agile way and to verify security on the way.

In the security field people like Gary McGraw have long been advocating ways of “Building Security In”. The Microsoft MVP Troy Hunt also proposes that you should “Hack yourself first”, instead of just waiting for the pentesters. Shouldn’t it be possible to weave these security activities into the process the same way as it is possible with normal testing activities using TDD? Indeed I, as well others believe it is so. Let’s look at how small extensions to an agile process can work in this direction.

Extending Sprint planning to deal with security

To start off you must first know what the requirements are. In a normal agile project this is done by eliciting User Stories from the customer or the Product Owner.

Let’s take an example of an online e-Commerce site. A User Story might be “As a customer I want to be able to add a review of a product so that information about products can be shared between customers”.

This works very well for traditional functional requirements, but for non-functional requirements a little extra thought is needed. In the case of security requirements it is often useful to state a requirement in a scenario that should NOT happen. In our case we shall call these scenarios “Abuser Stories”. These stories are non-technical descriptions of bad things you want to make sure you avoid. An Abuser story for this site might be:

“An attacker uses the Review Product-function to spread malicious Javascript”. Another might be: “An attacker abuses the Review Product-function to gain unlimited access to the database”.
A Product Owner might not be able to come up with these stories himself, but might need the help of a security engineer to help him with finding these threat scenarios.

read more »

The Candy Crush Soda Delivery Pipeline

Posted on by

Candy Crush Soda releases a new version of the game on all platforms every other week, year round. I’ve written about the delivery pipeline and the challenges the team faces on King’s tech blog: https://techblog.king.com/candy-crush-soda-saga-delivery-pipeline/

Screen shot King tech blog

Previous posts about working with the Soda team:
How We Developed Candy Crush Soda Saga
What Should We Build Next?

Schema migration, an important part of continuous delivery

Posted on by

Most of you have a relational database involved in your persistence. As soon as your first version has been set in use, you can’t change the database schema as easy anymore or you might lose valuable production data.

At the same time, continuous delivery demands that there should be as few manual steps as possible. See here for motivation on continuous delivery.

You no longer have a few database instance, there are numerous for different levels of testing and every developer nowadays run a personal database. To keep track of all database instances and keep them updated becomes a steep task.

To tackle this, we started using Flyway as a tool to manage our database scripts. Our applications migrates the database automatically on startup so we get a hands-free solution that will guarantee that the code and database schema is in sync.

Here is a technical recipe for accomplishing this when using Flyway in combination with Spring.
read more »

Continuous Delivery Lightning Talk

Posted on by

Here are the slides from my lightning talk at Crisp today on Continuous Delivery!

Hur man kan hantera Continuous Delivery med MongoDB

Posted on by

MongoDB är en schemalös, dokumentorienterad databas som har fått stor popularitet i den agila världen bland annat därför att man inte behöver underhålla något databasschema.

MongoDBs schemalöshet gör att många leds att tro att Continuous Delivery blir en promenad i parken, eftersom det ju inte behövs några datamigreringar när man driftsätter en ny version av koden!

Rent teoretiskt är detta sant, men är ett sluttande plan in i Land of Crappy Code™ !

För att slippa onödig komplexitet i form av varierande utseende på lagrade domänobjekt beroende på deras ålder, rekommenderar jag att man utför regelrätta datamigreringar även när man använder MongoDB!

Jag rekommenderar även att datamigreringen är en del av applikationen — till skillnad från skript som skall köras vid sidan av innan applikationsstart — helt enkelt för att eliminera risken för misstag.

Jag har i mitt sidoprojekt Varmfront.nu utvecklat en kompakt liten lösning som i MongoDB implementerar det som Flyway gör för SQL.

Mönstret bygger på Spring Data for MongoDB och Spring JavaConfig, och migreringarna är skrivna i Java. That’s right folks, no XML here 😀

Läs vidare, så får du se hur man kan göra!

read more »

Continuous Delivery vs Continuous Deployment

Posted on by

Jez Humble posted a blog entry with the same title in 2010, but if you haven’t read the entry, or just want a quick explanation, here’s the short version:

A continuous delivery pipeline automatically tests the application, but keeps the deployment decision as a manual step. A continuous deployment pipeline, on the other hand, will automatically deploy this working version. There is no “right” way. Different organizations have different needs. Use the one that delivers the most value to your customers!

The Future of Software Development

Posted on by

Whar are YPU doning in the future?

What will software development be like in the future? “Agile” as we know it, will not be around, nor will test-driven development, continuous delivery, or BDD-like methodologies. I’ve been pondering this for a while, and based on some observations and a dose of wishful thinking, I’ve arrived at the conclusion above. Do you agree?

read more »

On the Road to Continuous Delivery

Posted on by

Continuous delivery is a hot topic. A lot of people are talking about it, but implementation in the real world is scarce. I lucked out at my last assignment when I was at SVT (Swedish Public Television) and got the chance to work on implementing a continuous delivery pipeline.

When I started, the project had delivered once and was gearing up for its second delivery. Representatives from each team met, and we decided to aim for an (at the time) aggressive schedule of one release per week! Our first “fast” release would go out in January, and we would continue from there.

It would be nice to say that this worked out well and we were continuously delivering from then on, but this blog entry is about our road to continuous delivery, so my story starts here!

read more »

Bootstrapping an agile project with continuous deployment using cloudbees

Posted on by

Starting from scratch, this video demos how to quickly get to a fully agile project setup with continuous deployment.

Everything is in the cloud – GIT repo, Jenkins, MongoDB, and the app server. The system deploys automatically with every successful commit.

The app itself is minimal, but does have a simple web interface and a database. The idea is that once you get a “walking skeleton” app like this running in the cloud with continuous deployment, you can get user feedback early and often, and evolve more quickly.

The video demonstrates:

  • iterative development with VERY fast feedback loop
  • a dash of TDD
  • continuous deployment via git & jenkins & cloudbees
  • using eclipse tightly integrated with maven, jetty, and git.
  • the basics of mongo DB
  • the basics of java servlet development (I’ve intentionally avoided using a 3rd party web framework, as this setup will work for any web framework).