The current Jenkins build pipeline looks like this (plus lots of static analysis that doesn't fit in the picture):Ĭontinuous Delivery Pipeline with Load Test Step The code is built and passes through a variety of tests and checks at each step, with only a few configurations changing along the way, ensuring what is released has passed every step as quickly and consistently as possible (smooth is fast). The build pipeline is the process the code goes through from committing the code to eventual delivery, automated where possible to minimize the lead time for new features and wire in good practices I want to follow. The plugins don't feel quite as first class in TeamCity as they did in Jenkins, but the built in functionality was quite a bit more extensive, so I think this just comes down to focus and my own experience (or lack) with the tools.īut enough of my feelings, lets do some technical stuff. Rerunning steps in the build would create a whole new chain, rather then being treated as a retry of a prior run of the same snapshot. There also wasn't an obvious way to use a build chain view for the dashboard. The build chains were as close as I could get to a pipeline visualization and they are busier then the pipeline view in Jenkins. Little touches like previews for the artifacts and working directories were also extremely handy. Wiring together dependencies was far easier and clearer then in Jenkins, and the build-level configurations and sharing of build numbers throughout the build was a lot cleaner. I like the visibility of pending changes for each build step and everything I have implemented has been extremely straightforward (though I haven't taken on custom graphs and code coverage yet). I found several places where TeamCity would have been easier to use, such as parsing test result files and evaluating results. My general feelings towards TeamCity during this process have been good. Up until now, this was entirely on Jenkins, but today I intend to re-implement the pipeline on TeamCity. The journey included making changes to support unit testing, creating a CI build, adding automated multi-environment deployment, automated interface testing, automated load testing stage, and static analysis. Over the series of 12 posts, I have built a continuous delivery pipeline around the MVC Music Store tutorial web site.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |