All geek questions in one place

How do you constantly deploy a large multi-application system

At the moment, we are deploying the entire application chain together and immediately to production due to the many dependencies that the systems have.

Our Scrum teams are a business theme based on providing real business value at the end of each Sprint with each user story, so it often happens that user stories need to be changed across multiple applications.

And we have several Scrum teams working on the same systems. Logically, we are completing acceptance testing of everything in a huge adoption and (semi-automatic) regression test.

But to make a big hack for production is very time-consuming, error-prone and not scalable anymore ... (or is that so?). With continuous deployment, we would like the team to self-service the deployment before production, so the business deploys features when they want, and not based on an IT schedule.

But how do we manage to deploy the changes (code, database scripts) that are distributed across several code bases and find a strategy for solving dependencies between applications?

What is the strategy for scalable continuous deployment? And how do you get to this point?

What do you think?

+4
source share
5 answers

(These are quite a few questions in one big question.)

But I would like to refer to the book "Continuous Delivery" http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/

Edit: (As already mentioned, you have already read this book) Some suggestions that you can already make, but for others with a similar problem:

But I do not have a solid solution for the automatic dependency deployment strategy that you are really requesting: |

+2
source

There is no single silver bullet that will solve your problem, but Kwatee ( http://www.kwatee.net ) can go a long way in the right direction. Kwatee deals with distributed / shared applications on several servers, if necessary, and can take care of running preliminary DB ugrade scripts, etc. Using actions before deployment and after deployment. You can also configure settings for different deployment environments (dev, test, prod). Kwatee has a web interface that simplifies setup, but you can get the best of all worlds by including it (via CLI python commands or the Ant task) in a continuous integration tool.

+2
source

I use CruiseControl for continuous integration. It’s easy to set it up so that whenever someone checks something in the trunk, a build test and automatic regression are run. If the build or testing failed, all developers who have committed the code since the last build received an email with a list of possible changes. Devs that break the assembly (although not a regression test) should bring donuts the next day.

The specific tools you use for continuous integration and testing may depend on your language (s) and platforms, but the concept is the same. See http://cruisecontrol.sourceforge.net/

Hope this helps.

0
source

I answered a very similar question: Best practices for continuous integration and deployment

This may be worth checking out.

0
source

I could have misinterpreted, but I think that you say that acceptance tests for the whole system are complex and you want each Scrum team to be able to lift its own weight? I think that even if every Scrum team can perform some tests that you cannot release without going through the system testing phase prior to release. In other words, system testing is mandatory, but the frequency can be adjusted if each component can be tested separately with substituted dependencies. If isolated testing and small-scale testing can be performed by a separate Scrum team, then system tests can be performed once in 2-3 sprints, where the tester focuses on system testing, while testers focus more on bug fixes.

0
source

Source: https://habr.com/ru/post/1395633/

More articles:


All Articles