What is a Release Train?
It is a long running team of various feature teams, which work together with various stakeholders, develops incremental features that will be released to market as soon as its viable. The same team is also responsible for it operations, monitoring , reporting and hence its continuous process of learn , adapt and improve.
Why is its significance?
A Typical Organisation will have a number of teams working on a product/project/feature working in silos, every silo has its own release process and delivery. This most of the times causes delays in integration, testing and increase the time to market significantly.
A release train will bring all the silo's together towards a common goal, apply systems thinking to build a cross functional team. This team is then optimised to extract a business value and deliver it to production and continue to support it throughout its lifecyle.
The following diagram is the devops architecture that evolved after a number of years implementing DevOps in a major DIY UK retailer.
It illustrates the achievements and challenges faced whilst implementing a continuous delivery (CD) framework for a major retailer by using a rigorous but simple development process, integrated with Jenkins build pipelines on AWS and on-prem infrastructure. The pipelines have been carefully architected to orchestrate the various build, deployment, testing and release stages of ecommerce applications.
How does it work?
The cost of these services will pay for itself even before you know it.
Here are some of key process changes we implemented:
- Developer Environment: Implemented virtual machines (VMs) for developers so they have all the required tools and applications for executing builds and tests.
- Feature Environments: Every feature that was developed, that team would get an AWS feature full environment to develop and test the feature before merging code to main branch.
- Continuous Integration: Code already tested in Feature environments would be build again with other features on a centralised CI.
- Continuous Release: Continously the centralised CI would create well tested deployable release.
- Continuous Deployment: The deployable release would be continously moved forward to higher environments for various testing such as security/perfomrance before it lands to production.
- Automated Testing: Automated Fitness, Selenium (UI) , Rest Assured (API) and JUnit(unit) were integral part of each and every build pipeline, which makes the release stable to be release any point of time.
- Environment Configuration: The environment configuration was decoupled so that the release is environment-agnostic and separately deploys environment configurations.
- Database Deployment: Used tools such as DBDeploy to automatically keep the database base updated from the release.
- Production Deployment: Each release that was tested in performance environment was deployed to production every couple of weeks.
- ReportingJenkins pipelines were a wonderfull source of reporting along with Fitness and allure report for Automated Tests.
- Feature Stable Release:Each feature could be independently released to production.
- Faster Stable Release:Failures are detected faster and as such, can be repaired faster, leading to increasing release rates.
- Faster Mean Time to Resolution: Rolling back of features was very convenient for business in case of failure, also feature toggles were implemented to swicth off a feature if it was causing failures
- Reliable Code:With such architecture the code was stable and reliable most of the time, any code related issue would be identified and fixed in feature environments.