![]() In order for this to work successfully, developers need to apply the good development practices they’re probably already aware of but may not have previously had the impetus to adhere to. In theory, the continuous build process should look something like this: As a result, effective CI is only achieved through effective use of VCS. Pivotal to this is the version control system as this should be the source of truth for the code base. The CI objective is to continuously and frequently incorporate changes to the codebase into a centralised build process which may include the automated running of tests, analysis of the code and deployment to target environment(s). Actually, the Wikipedia info the CI link points to is very good introduction to the concept so it’s one you’re not familiar with, go there and read that before continuing because I’m going to be a lot more succinct than they are. ![]() Welcome to the realm of continuous integration or “CI”. I’m sure there are other good reasons but that’s a good kick-off for the moment. Version control – if you’re not deploying directly from your VCS, what confidence do you have that released source code is retrievable or reproducible? You’re (hopefully) not publishing all your source code to the target environment so short of some emergency reverse engineering, a developer could easily release code you’re never going to be able to reproduce.Either that or pulling a previous revision from VCS and repeating a manual deploy which can be both time consuming and error prone. I’d bet my bottom dollar that in lieu of a build and deploy environment, this is your rollback strategy. Rollback – you know how rollback is most commonly done? Copy the target folder and rename it “old_MyWebApp”, publish the new app then if it breaks, copy the old files back over.You could have a dozen releases in a day and be none the wiser because if it’s not automated, the information is inevitably not recorded or done so poorly. You have no way of automatically capturing when, what and who. They will bend to temptation and circumvent release procedures, even though it’s normally well intentioned (just had to turn off custom errors for a moment…). Access rights – you’re giving the developer too much if they can directly invoke Web Deploy either with their own credentials or other credentials they know.In all likelihood, your existing release process looks something like this: Deployment by developers directly from Visual Studio or command line with MSDeploy works fine most of the time but has a few flaws we’re simply not going to be able to overcome without a build and deployment server. Actually there are several bits missing but automation is the common solution. The bit that’s missing though is automation. ![]() Config transforms, packaging and Web Deploy are great stable mates in the world of web application deployment. Over the last three posts in this series, we got to the point where all the Microsoft bits are working really nicely together. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |