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.
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 »
Sometimes a continuous integration/delivery scenario is more complex than just building a system in a multi-stage pipeline. The system may consist of several subsystems, or just complex components, each of which requires a build pipeline of their own. Once all systems pass through their respective build pipelines they are integrated together and subjected to a joint deployment and further testing. When facing such a scenario, I decided to build the simplest possible thing that would work and get the job done.
Sisyphus, artistry, cult of quality, weaving, broken windows and all the other stuff you have to care about if you want to build high quality software. Here’s my speech on how we did it at Atex Polopoly, held at the SmartBear MeetUI user conference May 23 2013.
I ended my talk on the SoapUI user gathering MeetUI singing the stop the line song. Now it has ended up on youtube.
Here’s the text:
I keep a close watch on these tests of mine
I keep my Jenkins open all the time
I see a defect coming down the line
Becuse you’re mine, I stop the line
For all you heroes fighting a daily battles convincing teams, managers, tester, that deploying software work to production anytime using CI it’s possible, well here is a story that might encourage you. (Thanks to Xavier Allue).
In the 1950’s, a japanese team struggled with a big die press. The die press could not be changed to new conditions fast enough, so they always had to work with big batches in order to make up for lost setup time. (big software project ring a bell?). The team decided to get that setup time down from double digit to single digit number. It took them years. But – they actually finally made it.
At the time, there was an alternative point of view:
"While these japanese guys like to promote the notion of fast setup
changes, this simply isn’t viable on very large scale activities. For
example, this die press here next to me uses 3-ton dies and takes five
foremen a full day to configure…"
