Fix OpenMRS link

source/posts/2017-10-10-architecting-continuous-delivery.html.markdown.erb

@@ -56,7 +56,7 @@ For a start, shared components (like a pagination UI component or a library to m
 
 But when there are multiple functional teams working on the same repo, the biggest payoff comes when you can separate out each team's work into components to be managed in their own repos.
 
-One large-scale Open Source project doing this is the [OpenMRS](https://wiki.openmrs.org/display/docs/Modules) application where independent modules are wired up together in the application runtime. A component in this case is a binary dependency that includes end-to-end functionality of a module including the UI. Deployment of a component can be managed on the deployment pipeline and means upgrading the component version on the parent application.
+One large-scale Open Source project doing this is the [OpenMRS](https://openmrs.org) application where independent modules are wired up together in the application runtime. A component in this case is a binary dependency that includes end-to-end functionality of a module including the UI. Deployment of a component can be managed on the deployment pipeline and means upgrading the component version on the parent application.
 
 On one of our projects where we saw the pains of a large team working on a monolithic content management system (CMS) codebase in Java, we started to break out components under active development into separate repos. For example, the search functionality was separated out. Then, everything related to search - from UI to backend code - could be developed on a much smaller codebase. The binary artifact, in this case a JAR file, could then be plugged in as a runtime dependency on the application. We then had a small test suite on the main application build pipeline to validate that the component worked well within the application boundaries.