Have you ever achieved it in your company? I have worked in a couple companies and yet have to see it done the ultimate way.
Mostly it boils down to a combination of one, if not all, of these problems
- not enough resources (invalid manager or lazy peon argument)
- to many stakeholders and all use the same environment(s)
- data is constantly changing, data is polluted
- silo’s
- unstable releases of dependencies wrecking tests
- no automation what soever
- no integration testing whatsoever (no kidding, it happens)
- no build server ( huh what? you still build on your local machine??)
- a backward ops team reluctant to do cool stuff
you can probably find some more reasons! feel free to let me know.
So let’s create a situation. Let’s say you have a simple infrastructure:
- database servers
- micro services ( API’s)
- front end applications
All of them being built by different teams.
- Team DB does databases,
- Team MS builds the java backend services
- Team FE does some nodejs fronted magic
Let’s also assume you have at least 3 different environments: development, test and production. Each of them a version of all applications on it.
Suppose that you have at least the problem of data consistency and unstable test wrecking dependencies. Then your current scenario could be something like:
- Team DB updates a database schema Z to version 2, tries it out on development. “Yay it’s works! Our update scripts are mighty cool! Let’s rollout to test.“
- Team MS, sitting close by, quickly noticing the failing build on the CI Server. “Ho Ho Ho! Wait let us update our service Y that uses your update DB X.“. Update done, deploy to development. Runs some tests to verify that implementations correctly use the new database with it’s new functionalities . “Yay it works! Rollout to test!” Run the integration suite all seems fine!
- BOOM, front end was just giving a demo to stake holders on the test environment. An angry product owner with on it’s tail 15 nodejs developer storms in the back end room shouting all over the open space. “WTF #$FJIEAÏOXCBVEEEE$HIT# what where you thinking releasing that to test! We search a street name in your service and we get only cities back! And the search name we initially use in our demo isn’t there anymore!! You broke our whole front end! Fubar our demo! AGAIN !”
Frustration, depression, the downfall of the team spirits, the downfall of a company, IMPEDIMENTS.
Well now! WE ARE ALL SAVED from this! Just call 1-800-DOCKERIZE – warning next up is simple theoretical docker porn
Okay, I might have slightly exaggerated the story above.
But how can we solve this impediment. The answer to that could be docker. ( It is most likely not the only answer ).
Why Docker? Docker is a lightweight platform to build and ship applications, we will use it to create our development and test environment. Read more about it at the docker website.
How do we do it?
First you need to have docker setup on a couple of machines ( or 1 to start with ) but that part we’re not going to describe here. There is enough info about all that already. We will stick to a theoretical basis.
For the above scenario a possible solution could be that each team provides docker based images of it’s deliveries. Each different team, could then use the image of a certain version it needs to do it’s testing or demoing. Preferably a stable release of the others team docker image!
It might look like a lot to setup. But it’s well worth the results.
Team DB would provide a base image of the schema with some testing data. The 3 teams together should agree on the data that should be in this testing dataset. ( This might be the most painful part of the setup 🙂 ). It is important that there is an agreement on this dataset between Team DB, Team MS and Team FE. It is also evenly important that this basic dataset should not be changed without mutual consent. Since this is the set that should be used for integration testing and demo it is a mission critical part that should be handled with care.
Team MS has to provide one, but preferably multiple docker images of their micro services that use the base image of Team DB as dataset. They could opt to group all their service in one docker image and so ensuring compatibility between their services.
Team FE uses the correct docker images to program against and to prepare demo’s / integration test. Since all teams have agreed to keep those stable, Team FE will never ever have a issues during demoing. No more angry nerds standing at a developers desk shouting “WTF #$FJIEAÏOXCBVEEEE$HIT#”
If you have openminded developers that are keen to learn some of the next big things and not scared to go where none of them had gone before the technical part will not be difficult. Docker isn’t that hard. It’s fun. The greatest challenge is getting your teams doing it together!