[Progress Communities] [Progress OpenEdge ABL] Forum Post: Startup procedures & blue/green deployment

Status
Not open for further replies.
H

hutcj

Guest
We have a fat ChUI/tty application that serves a few hundred direct connect clients. Recently, we implemented a blue/green deployment model. This has had a number of benefits such as preventing issues caused by compiling into the live rcode directory and having the old version ready to switch back to in case something goes wrong with the new version. In short, there is a "blue" and "green" directory on the production server where all the build artifacts of the application such as startup scripts and rcode are deployed. The user login script reads in the active environment from a text file and then proceeds to run the blue or green version's startup script, whichever is currently "active". Whenever deploying a new version of the application, build artifacts are copied to the currently "inactive" directory where it can be verified before releasing. When all is confirmed, an admin script is run to switch the active version listed in the environment text file. This has worked flawlessly for new sessions. However, we are having trouble getting active sessions switched over to the new environment. It is easy enough to detect the change from the primary startup procedure and manipulate the PROPATH to point to the new environment. However, if the startup procedure itself has been changed, there is potential for run-time errors for active sessions when the switch is made. Is there any way to force a restart of the ABL startup procedure? I have done some tests, and if the application encounters an error or the user CTRL-C's, the startup procedure is re-loaded from the updated PROPATH. But I don't have a way to restart the procedure. I considered doing something like RUN start.p followed by QUIT or something, but this would just make the old version a parent procedure and the new version a child procedure. In a bash script, you can prepend any command with "exec" and that will cause the new command to actually replace the current process - anything after that statement would not be executed. I don't think ABL has anything like that. I know it is also feasible to just force quit the session after displaying a message that the user must re-login, but am looking for something less intrusive - hoping for a seamless, automatic switch to the new environment. Another consideration was to just let the active sessions continue on running the previous version, but this came with other problems. What if we deployed new changes and switch environments twice while the session was active? Then we have compiling into live rcode directory problems again. What if the change involved a database refactoring? Running the old version could cause errors. One might also argue to only switch active environments when there are no active sessions, but the tolerance for down time is always becoming stricter, and there will inevitably be times that a bug needs to be fixed ASAP with an immediate release. Any ideas? Is forcing the session to quit the only viable option?

Continue reading...
 
Status
Not open for further replies.
Top