Government Digital Service, part of Cabinet Office

WP1877: Upgrade GOV.UK publishing applications and a discovery into dependency management processes

Incomplete applications

8
Incomplete applications
6 SME, 2 large

Completed applications

10
Completed applications
10 SME, 0 large
Important dates
Opportunity attribute name Opportunity attribute value
Published Monday 11 May 2020
Deadline for asking questions Monday 18 May 2020 at 11:59pm GMT
Closing date for applications Monday 25 May 2020 at 11:59pm GMT

Overview

Overview
Opportunity attribute name Opportunity attribute value
Summary of the work The work has two different strands as follows:
1a. Upgrade all GOV.UK publishing applications to Rails 6
1b. Upgrade all GOV.UK publishing applications Ruby 2.7

2.Review the GOV.UK dependency management processes and make recommendations as to how to reduce the burden of the day-to-day management of these.
Latest start date Monday 22 June 2020
Expected contract length 3-6 months
Location London
Organisation the work is for Government Digital Service, part of Cabinet Office
Budget range £133,000

No more than £750 per resource per day.

About the work

About the work
Opportunity attribute name Opportunity attribute value
Why the work is being done Implement a more secure, stable and scalable platform in line with innovation.
Strand 1:Development work

1a:Upgrade up to 45 applications to Rails 6.
Mini investigation to confirm approach and scope
(no greater than 160 days)

1b:Upgrade up to 65 applications to upgrade to Ruby 2.7. Much of this of this work is automated but ultimately applications need to be hard restarted to pick up the new ruby versions so a formal roll out possess needs to be in place and co-ordinated with GOV.UK technical support (5-7 days)

Strand 2:Discovery (7-10 days)

We would like the supplier to conduct a mini discovery/technical spike into options and delivery recommendations for dependency management that minimises manual intervention while balancing our desire to stay up to date, but not fall foul of bleeding edge vulnerabilities for the GOV.UK platform suite of micro-service (between 60-70 apps) applications running on Ruby on Rails technologies.

This should include what applications and processes are impacted and make recommendations about options and best practise for us to reduce the oversight and burden the technical team currently undertake to support these in order to drive efficiencies and reduce technical overheads in regards the management of the GOV.UK platform.
Problem to be solved The GOV.UK Technology suite needs to be kept up to date to mitigate risks around security, vulnerability and interoperability. It is also important that GOV.UK is enabled for new technology developments.

Reducing any technology overheads and manual burdens within the dependancy management system also mitigates risk of security and human error whilst allowing the tech team to be as efficient as possible.
Who the users are and what they need to do 1a & 1b
As a Technical owner of GOV.UK
I need to ensure our platforms are up to date
So that our environment and the citizen facing website is stable and reliable and that the developers who work on GOV.UK can interoperate with other services and new technologies.

2.
As a developer on GOV.UK
I need to have a process and the tooling to update dependencies on my applications in a way that minimises the workload across all applications
So that we can help ensure our applications are secure, performant, and
And so that time is being spent efficiently
Early market engagement None.
Any work that’s already been done We've started doing the Rails upgrades but have made limited progress on the 45 applications in scope.

Initial conversations regarding the issue of dependency updates in general, but there's no formal "discovery" been done.
Existing team The supplier will predominantly be working with The GOV.UK Head of Tech and GOV.UK Tech Leads.
Current phase Not started

Work setup

Work setup
Opportunity attribute name Opportunity attribute value
Address where the work will take place The team are based at The Whitechapel Building in Aldgate in London.
Working arrangements The supplier can primarily work remotely and work with the teams via digital communication methods. The existing team of GOV.UK developers will be available to review Pull Requests and answer questions on undocumented application behaviour. They will specify the versions of dependencies to be upgraded at the time the engagement begins. The work will be co-ordinated by a GOV.UK Delivery Manager and overseen by a GOV.UK Senior Technologist. It would be beneficial for the supplier to be onsite for key workshops, briefings and outcome sessions. No expenses are anticipated.
Security clearance Minimum Baseline Personnel Security Standard

Additional information

Additional information
Opportunity attribute name Opportunity attribute value
Additional terms and conditions All expenses must be pre-agreed with between the parties and must comply with the Cabinet Office (CO) Travel and Subsistence (T&S) Policy.

All vendors are obliged to provide sufficient guarantees to implement appropriate technical and organisational measures so that the processing meets the requirements of GDPR and ensures the protection of the rights of data subjects. For further information please see the Information Commissioner's Office website:https://ico.org.uk/for-organisations/data-protection-reform/overview-of-the-gdpr/

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Skills and experience
Opportunity attribute name Opportunity attribute value
Essential skills and experience
  • Demonstrable experience of technical migration
  • Demonstrable experience of delivering architectural consistency
  • Demonstrable experience of consolidating features
  • Excellent verbal and non-verbal communication skills - provide an example of both
  • Show in an example at least 5 years experience of Ruby development
  • Show in an example prior knowledge of AWS and SW3 (minimum 2 years experience)
  • Show in an example how your team has strong team-work skills
  • Show in an example previous experience of working with Asset Manager or similar tools
  • Demonstrable experience with large scale file upload management on Linux Systems
  • Show in an example experience with a cloud based storage system.
  • Show in an example at least 5 years experience with Legacy Rails applications
Nice-to-have skills and experience
  • Experience of the GOV.UK Stack or another public sector Stack
  • Experience of providing instruction and documentation to enable learning
  • Demonstrable experience of working in an agile environment
  • Previous experience with GOV.UK stack

How suppliers will be evaluated

All suppliers will be asked to provide a written proposal.

How suppliers will be evaluated
Opportunity attribute name Opportunity attribute value
How many suppliers to evaluate 3
Proposal criteria
  • Approach and methodology
  • How the approach or solution meets user needs
  • How they’ve identified risks and dependencies and offered approaches to manage them
  • Team structure
  • Value for money
  • How the approach or solution meets your organisation’s policy or goal
  • How to manage Risks and Dependencies associated with Strand 1 and Strand 2
  • Estimated timeframes to delivery Strand 1 and Strand 2
Cultural fit criteria
  • Work as a team with our organisation and other suppliers
  • Transparent and collaborative when making decisions
  • Have a no-blame culture and encourage people to learn from
Payment approach Time and materials
Additional assessment methods
  • Work history
  • Presentation
Evaluation weighting

Technical competence

75%

Cultural fit

5%

Price

20%

Questions asked by suppliers

Questions asked by suppliers
Supplier question Buyer answer
1. Who is the incumbent at the moment At the moment, there is no incumbent supplier doing the work
2. This budget seems like it is for one person, is this correct? The budget can be for multiple people if that is how the supplier wishes it to be.
In particular for the upgrade, so, you can either have 1 person doing all the upgrades, which will take longer, however if the supplier wants to put multiple people on the upgrades, then this will take less time - but the same budget.
3. We note that the first and fourth questions on the "nice to have""
criteria both ask for experience of the GOV. UK stack, but the first
allows for an equivalent Public Sector Stack.

If we have GOV. UK stack experience, can we use the same example for both?
Using the same example for both criteria listed is fine
4. Who is responsible for the testing of the applications after an upgrade? There isn't much time assigned to fully understand what each of them is intended to do and therefore be able to verify their status. The supplier is responsible for testing, but assistance in understanding the applications can be obtained from GOV.UK product teams.
5. Please could you confirm further aspects of the stack. What is the hosting provision? etc Ruby/Rails applications deployed via Capistrano to provisioned virtual machines. Docker-based development environment. More detail is available in our public developer documentation (https://docs.publishing.service.gov.uk/manual/learn-govuk.html)
6. how much valuable automatic test coverage is there? High coverage in our automated unit and end-to-end integration tests, although the latter doesn't cover all the applications. Manual feature testing will still be required.
7. What is the intention behind "Demonstrable experience of delivering architectural consistency" and "consolidating features"? GOV.UK's architecture is built up over dozens of services. Dependancy management across all of these in an effective manner requires consistency in approach and implementation that works across the board, but which may also require centralising some functionality.
8. Please could you provide a link to the mentioned "Asset Manager" https://docs.publishing.service.gov.uk/apps/asset-manager.html
9. What is the current level of unit, functional and integration test coverage for the apps? Are there any outliers where coverage is particularly low? Unit test coverage is high across our estate. Most applications also have good coverage through end-to-end integration tests. Manual feature testing will still be required.
10. Please could you provide a breakdown of the Ruby and Rails versions that the apps currently use? All applications to upgrade are currently on Rails 5.1 and Ruby 2.6.5.
11. Do the apps make heavy use of third party gems that may have been deprecated, or are not supported on more recent versions of Ruby or Rails? Not to our knowledge, although identifying cases where this might be the case and finding solutions is in scope for this work.
12. What is the typical size of the codebases for the apps? The codebases vary significantly in size and complexity. The vast majority of code is publicly viewable at https://github.com/search?l=Ruby&q=topic%3Agovuk+org%3Aalphagov&type=Repositories (not all products listed here are in scope for this work).
13. Do the applications use any legacy database connectors, for example the mysql connector (which has been deprecated in favour of mysql2)? Not to our knowledge, any application use legacy database.
14. "In the sentence “Show in an example prior knowledge of AWS and
SW3 (minimum 2 years experience)”: do you mean Amazon S3
instead of SW3? If not, then what are you referring to?"
This is a typo, and is referring to AWS S3.
15. In the sentence “Show in an example previous experience of working with Asset Manager or similar tools”: do you mean this ( https://github.com/alphagov/asset-manager ) Asset Manager? Yes, this is the type of examples of previous experience we want to shown in supplier bids.
16. In the sentence “Show in an example at least 5 years experience with Legacy Rails applications”: How do you define “Legacy” in this context? Applications that have been built over a number of years, including being upgraded through at least two different major versions of Rails.