DevOps, Development, SWOT

3 Threats to DevOps Implementation

Onboarding new clients to an agency is a tough job, and as such, there is a lot of things that one must consider to ensure a successful technical customer transition into your development agency. 
Despite current technical tool sets possessing deep sophistication - developers and admins are still using legacy methodology during the custodial changeover of client code. 
A considerable number of DevOps implementation cases will be porting old code and practices to a completely new and doctrinally different methodology. With that being said, I’d like to address some of the key blockers that you’ll face when bringing on new clients to the agency. 


#1: Code runs on old software

There are many cases where a custom app requires a certain version of php that is very much out of band or no longer supported. This can slow your onboarding process considerably. Many agencies have a certain stack they like, which can cause assimilation issues, since you now have to stand up a custom corner of your hosting network to let the code run while you rewrite their application to work in a non-legacy environment.  This can be fixed by discovering the exact version and accompanying modules, and building a custom docker image using Jenkins or Docker Hub - and testing it real world before cutting everything over. 

#2: No version control

When sites are not developed, maintained and possessed in some sort of source control system like GitHub or BitBucket, it is very difficult to look back and see what.changes were made to the code that caused certain problems. Anybody can zip up and copy code over, but there could be something missing. Likewise, you will likely run into trouble that, like mentioned before, would likely be easier to troubleshoot if you have a good history.  The best thing to do here is to get everything into source control that you can, and make sure the code you have in source control can run if you deploy it into your environment. Only after you certify that it runs, should you then begin to work with the code from that specific code base. 

#3: 3rd-party friction

There are cases where 3rd parties maintain some part of the customer web application, and those 3rd parties come with your new relationship. It is best practice to get integrated with key technical players at the 3rd party before taking custody of the client code. Often times, they prove to be blockers during custody changes or migrations because their focus is only the single piece or stake they have in the system you just took ownership of. These are people you will need to be in the most communication with during the technical lift of the customer application. It is also worth noting that lost of 3rd party vendors (custom extensions for wordpress or magento, xml feed providers in the aviation industry, etc.) tend to not be very. DevOps aware, so it is important that you have a procedure for integrating 3rd parties into your flow, without requiting them to make business changes themselves. 
Rick Conlee

Rick Conlee

Rick is an entrepreneur and networking expert who has spent the last 2 decades designing, building and maintaining special use case technology implementations for government institutions and private industry.