In our first article, we talked a bit about the emergence of OSS (Open Source Software) and why it looks the way it does. Then, we delved into the pros and cons of using software built on open source code. Following that, we discussed some tips and tricks on how you and your company can establish a stable organization capable of assessing various OSS initiatives and aligning them with the company's business processes. Afterward, we went deeper into the methods and tools you can use to facilitate work with OSS. We also discussed how to determine the activity level and security awareness in different source code projects. Now, we intend to focus on lifecycle management and how you can work with it.
Updates
Like most business-critical systems, it's essential to have environments beyond the production environment that everyone uses. Common environments that many use include:
DEV - where you can experiment with various things without affecting others.
SYS - a test environment where you can also include other components for testing.
ACC (internal) - here, the next version can be tested before moving on to external tests.
ACC (external) - here, the next version is tested with external users before entering the production environment.
The advantage of setting up the above environments is that you create a less vulnerable environment for your system, reducing the risk of unforeseen issues when introducing new versions of the software. Once you have created your environments, it's time to consider the update strategies you want to use. You can't avoid it; there will always be new versions of the software for various reasons. A smart approach is to allocate time in the calendar for updates, doing it regularly, perhaps once per quarter or similar. Simultaneously, have a process in place for handling more urgent fixes that need to be addressed.
Don't forget to create detailed instructions and checklists describing how installations/updates should proceed.
Compatibility
As mentioned in the previous article, today's applications often face the challenge of depending on many other components outside the project. Therefore, when updating the system to a new version, it's crucial to hold on and check/test that all involved components are compatible with the new version. Often, when upgrading one component, it may pull along several other updates because it requires newer versions of other parts of the system. Here, you can also benefit from the different environments we created earlier and thoroughly test everything before moving on to the other environments, especially before deploying the system into production.
Remember to use both manual user testing and automated system testing where you have defined everything in advance to ensure that new versions work as intended.
It's also important to consider legacy code, older code that you may not have full control over and may not be easily updated to the latest versions. Sometimes, this may conflict with essential updates that need urgent installation. It could be a significant security vulnerability that needs an urgent fix. However, the update might make the legacy code stop functioning, presenting you with a dilemma. In the short term, you may find a workaround, but in the long run, you may need to consider how to get rid of the legacy code and replace it with more modern alternatives. Another option is to virtualize and isolate your older code so that all dependencies can remain, but everything exists in a more protected environment and avoids exposure to the outside world in the same way as other parts.
CI/CD pipelines
Automate as much as possible without compromising on quality/security! There's probably nothing in the IT industry that has caused as much trouble as the human factor. Computers are simply much better at performing monotonous, repetitive tasks than humans. However well-crafted our checklists are and how clear and pedagogical they may be, we will never be able to eliminate the risk of human errors. Therefore, it's essential to try to incorporate as much as possible into your pipelines for both CI (Continuous Integration) and CD (Continuous Deployment). In our blog series on creating the optimal development team, we discussed CI/CD pipelines and what is important to consider. Feel free to take a look at that article for more tips and advice. In your pipelines, you can include things like testing (SAST/DAST, performance tests, penetration tests), and more. In principle, most pipelines usually consist of three different stages: build, test, deploy.
Version control
Many OSS projects (almost all) use some form of version control, such as git or something similar. This makes it much easier to track changes in the source code and all dependencies on other applications/libraries. If you track all changes made, it also becomes much easier to revert to an earlier version if you discover that something is not working. It may seem like this doesn't need to be a significant problem, but you will realize how important a version control system is when you suddenly need to roll back several versions, perhaps three or four versions back in time.
Communicate with the current community
As discussed in earlier articles in this series, there are many different opportunities to engage in an OSS project. Our advice to you, considering bringing in various products based on open source code, is to connect with the different projects. Why not contribute to the further development of the projects or get a chance to be involved and influence the system's future direction/development? Even commercial companies offer opportunities to influence in various ways with user forums and such initiatives, but in an OSS project, you have the opportunity to contribute in a much more concrete way than just coming up with ideas and suggestions.
If you are more involved in an OSS project, you automatically become more informed about what's happening in the future and can better prepare for upcoming changes and paradigm shifts.
Managing the lifecycle of open source code requires a balance between keeping your software updated and secure and minimizing disruptions and risks. By following these guidelines, you can build an effective strategy for managing and updating the OSS projects you use. Now that we've discussed a bit about lifecycle management, we intend to provide more concrete tips on how to think about integration with your existing systems in the next article.
