• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

Pipeline as Code: Introducing CI/CD in a legacy and large codebase

Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good day,

What are the guidelines to follow and pitfalls to avoid if you want to introduce CI/CD in an existing legacy project with a large codebase?
Posts: 18
Java ME Quarkus Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the CI/CD perspective, I don't think it makes much difference whether it is legacy or brand new (if by legacy, you mean systems that do not have automated test as it is provocatively defined in Michael Feather's book "Working Effectively with Legacy Code") codebase. The same principles still apply - you need to achieve certain level of maturity in various levels of your software delivery as I explained in the other thread here: https://coderanch.com/t/741354/engineering/Pipeline-Code-Practices-CI-CD.

The first priority when dealing with such a system is usually to create an automated build process if one does not exist. Then maybe the next priority would be to create an automated functional functional test scuffolding around it. Creating automated tests will be easier if documentation or the team members are still available (might not be the case). This activity could be hard as from the business perspective, you're spending time on what seems like "low-value activity" - if the legacy system is already in production and working "fine". Once these smoke tests are in place, you can begin with layered approach to your automated tests. The first layer being very simple and fast-running tests for problems that prevent you from doing useful testing and development on whatever functionality you are working on. The second layer tests the critical functionality for a particular feature. This can sometimes be harder that it sounds. Systems designed to be testable tend to be more modular and easier to test thant those that are not. However, this should not divert you from the goal. It is important to remember, that you should only write automated tests where they will deliver value - the vast majority of regression bugs are caused by altering framework code, so if you are only adding features that do not require changes to the underlying framweork, there is little value writing a comprehensive scuffolding (however, the exception to this is when your sofware has to run in a number of different environments - in this case automated tests combined with automated deployment to production-like environments deliver a gread deal of value since you can simply point your scripts at the environments to be tested and save yourself a lot of effort on manualt testing).

Good luck!
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic