CASE STUDY IT. Albumprinter Adopting Redgate DLM

Transcription

1 CASE STUDY IT Albumprinter Adopting Redgate DLM

2 "Once the team saw they could deploy all their database changes error-free at the click of a button, with no more manual scripts, it spread by word of mouth. The value was obvious and everyone was on board with the process change." Sjors Takes, DBA at Albumprinter How would you move a database that supports 25 different applications out of manual development and into a continuous delivery process? Could you do it in just a month and a half? That s what database administrator Sjors Takes and the development team at Albumprinter pulled off when they adopted Redgate DLM. Here s how they did it. 2

3 Background Albumprinter, one of Europe s leading photo product companies, employs 280 people in its manufacturing plants in the Netherlands and Norway. 60 people work in the company s IT department, developing and maintaining the databases and applications that keep Albumprinter running, powering everything from websites where customers can design photobooks, to the workflow in Albumprinter s manufacturing plants. In late 2013, the team began adopting an agile way of working, focusing on continuous delivery, use of microservices, and cross-functional teams. There were three main drivers behind the change: 1. Quickly delivering new features, based on customer feedback, to Albumprinter users. 2. Ensuring that software updates were robust, by deploying them with a proven solution that works all the time. 3. Providing a lean environment where developers could focus on developing, not packaging deployments. Starting the path to CI for the database We started towards continuous delivery with the simpler parts our APIs and code, says Josh Marcus, Albumprinter CTO. At that point, Sjors, our DBA, came to us and said, We need to do something here for the database. Let me look at a couple of tools. I learned to use source control at Albumprinter, as part of my work with the development teams, explains Sjors. But for the database, the team wrote change and rollback scripts, which they stored in Subversion a manual process. One day, a senior developer came to my desk and asked, Can we use source control directly? I d been learning about Redgate s CI and source control products through SQL Server Central, so I said, I m reading about it now. I was just about to propose that too! That s when it all began. I attended a Redgate DLM Workshop in Cambridge, which covered source control and database CI and, from that, I could set up a proof of concept at the office. 3

4 Setting up a pilot program Whenever we try something new, a small team pilots the changes, says Josh. We ve found it really helps with the process. The team tries a new way of working as an experiment and, if they like it, the idea starts to spread naturally throughout the company. In the case of DLM, once the team saw they could deploy all their database changes error-free at the click of a button, with no more manual scripts, it spread by word of mouth. The value was obvious and everyone was on board with the process change. The teams really worked together to make it happen. The DLM pilot took about a month and a half, from initial trials to full implementation. For Sjors, it was quite a challenge. We have seven development teams, one of which works with a single database that supports 25 applications a big one! he says. I started with them, because it was the hardest database to source control. I learned a lot by fixing problems that came up there, but realized we had to define a process first because of the interdependencies involved. I moved to our other team who work more on the database side, with smaller applications, and put the knowledge that I d gained to work. I started configuring everything for them at the start of 2015 by putting all their databases in source control. By the end of January, I succeeded in introducing continuous integration as well, using Redgate tools and TeamCity. DLM in practice and the next steps For every database, we have one repository and one build configuration which watches the repository, Sjors continues. Every time someone checks in, a new build is created. When someone decides to deploy, they can get a new build from the Subversion repository. We use four environments a classic Development, Test, Acceptance, Production setup. Once a build is deployed to Development, it can be promoted to the other environments in order. We use Octopus Deploy for the application and database, with Redgate tools picking up the new package for the database and deploying that alongside the application. 4

5 The database is still in Subversion and the applications are in Git. In the future, I want this aligned, so we can look through the whole application in one repository. The CI process also raised a few questions, because our two teams have different ways of working. On one side, the team was very excited one of the senior devs even said, I can t wait to have the databases in CI. But the team that look after 25 applications supported by one database have a different way of working, because of those interdependencies. We ve now defined the process we need and we ll shortly be introducing source control using Git, followed by continuous integration. Ultimately, we hope to be able to turn the giant database into a set of smaller ones. Quick updates, greater productivity, higher morale The benefits have been substantial for us, says Josh. The goal was for all our teams to be able to deliver updates to production as soon as their code is ready, by themselves. We should be there this summer. What we re already seeing through continuous integration is that by automating deployments, we have a proven solution that works all the time. That s got rid of a lot of the quality issues with the deployment process and created a more lean environment where developers can focus on developing. It also means we can get value to customers sooner, with quality feedback loops and faster releases of features. From a lean perspective, developers are more productive in valued added tasks, so we re actually doing more with fewer people. A further benefit we didn t anticipate was that automation showed us our dev, test, acceptance, and production databases didn t match. As part of putting the databases in source control, we had to clean them up, which cut errors in the deployment itself. Issues with deployments have now almost all gone away, because we ve automated the process and created a repeatable solution. We re able to deploy to our two manufacturing plants with a single process, which saves us a lot of time and effort. 5

6 Since we ve changed the organisation and started disseminating knowledge what is continuous delivery, what is agile, how can we work better the barriers between teams have been torn down. For example, a lot of what we did also enabled our developers to set up their own database environments for experimentation, which was another advantage of continuous delivery and source control. Developers are more productive, too. For me, that s great because my team can do more with the same people. In one team, for example, one developer had to spend half his time every week packaging everything up and preparing for deployment. Once we d implemented deployments for his team, that part of his job only took a couple of hours. For them, it s been a huge morale boost. Developers don t want to spend time configuring deployments, or working out why things broke. They can get on with what they re best at: developing. For me as a DBA, one big key benefit is that I can do code reviews much easier and faster, says Sjors. We re on the way to full blown continuous delivery and that s my dream! You can read more about how Sjors Takes is building a database deployment pipeline on his personal blog at Find out more about how Redgate can help with your DLM process at