When you are setting up your Continuous Integration build definition in Visual Studio Team Services (VSTS, formerly Visual Studio Online) you will get a NuGet Restore step that by default will work with any standard NuGet feeds. However, if you try to build your solution with Sitecore NuGet references it can’t download the packages. Time for your NuGet.config!
It is very fashionable to apply a single word to pretty much ANYTHING to try to get in on the latest trend. The current ‘Whatever-Ops’ trend (MarketingOps, ChatOps, OpsOps) is one such example. For a while, though, we’ve been having the word ‘Continuous’ thrown in front of a whole lot of activities in the software development world: Continuous Delivery, Continuous Improvement, Continuous Management. There’s a reason for this… repeatable processes are a key ingredient to predictable delivery. And predictable delivery means money in the bank!
On the fourth day of Christmas, my true blog gave to me:
We all love checking out tools, so here are four Continuous Integration applications you can put under your tree this Christmas!
Continue reading “Fourth Day of Christmas… Continuous Integration tools!”
Wednesday afternoon, while at the DevOps East Conference, I attended a Continuous Integration (CI) session delivered by Chris Riley (@HoardingInfo). Chris was sharing his past experiences with CI and how to best roll it out to all types of organizations.
I particularly liked his suggestion of putting the QA team front and center, as I agree that there are few groups better suited to caring about the end-to-end cycle of delivery.
During the session, Chris offered his definitions of DevOps, both the practice, and the movement. It was during this discussion of the ‘fluffy’ side of DevOps (people, processes, and journeys) that I realized I was definitely a Fluffy DevOps kind of guy.
Are you finding that your TeamCity Powershell scripts are always returning exit code zero (a success) no matter what happens? Even when an exception is thrown and you can see the error message in your build log?
I ran into this problem recently while moving some of my Powershell scripts into script files in source control. It turns out this is not an issue in TeamCity, but rather caused by a bug in Powershell itself. Never fear, there is a workaround!
Continue reading “TeamCity PowerShell scripts run with “- File” always return exit code zero”
Over the last few years, I’ve been trying to iteratively improve our own processes at nonlinear to deliver better Sitecore solutions and set our clients up for maintainable and sustainable ALM processes. Some of my posts on automated Sitecore deployments with TFS or TeamCity outlined some of the initial steps we took in automated deployments. Recently, we posted a brief series to help folks getting into Application Lifecycle Management:
The first new piece of content I put together on this was a slideshare introducing ALM concepts of tool and process improvements, just to get people thinking about where they are in the process and what they need to change. I also covered how to achieve this with continuous improvement model, instead of trying to do a big-bang delivery.
The second piece I wrote covers why ALM matters for Sitecore (and pretty much any web application). The post covers some of the primary benefits of ALM, as well as how to apply ALM processes during your Sitecore implementations.
The third piece, written by my colleague Mauro, highlights some tips for automated testing of Sitecore implementations, specifically with Selenium. He’s been doing some really awesome things with automated testing of Content Editor, Page Editor, and the end-user flows.
The recommended reads:
I had planned on kicking off a short series on how to tackle the challenges of Sitecore Continuous Deployment, but after I had written my post the Sitecore Virtual User Group (SVUG) held an online Q&A presentation by Jason Bert on Continuous Integration & Deployment. The presentation is a great introduction to the concepts and challenges.
Some notes on the presentation
TeamCity (build), Git (source control), Octopus Deploy (deployment), and Sitecore Courier (create update packages).
Have you encountered a failure while executing an automated Sitecore deployment with TDS where the type initializer throws an exception and you are asked to reinstall the TDS application? Apparently, if your TDS installation becomes corrupted somehow, you need to get rid of the web service and let TDS reinstall itself. This might occur if you upgrade versions, at least, it did for me! Here’s how to handle the issue…
Have your deployments to Sitecore 6.6 installations been taking a very long time? Do your build logs show 3-4 seconds for every template item that is deployed? Are you seeing the following warning in Sitecore logs?
All caches have been cleared. This can decrease performance considerably.
If so, you are probably running on an older version of TDS. I recently ran into this problem with our TeamCity installation that was using TDS 220.127.116.11 to execute deployments. Simple deployments were taking over 30 minutes, sometimes up to a full hour. We brought that down to 5 minutes or less by simply upgrading to the latest version of TDS.
If you’ve been using TDS to do automated deployments for Sitecore, you’ll eventually need to start deploying to a new environment. Maybe you’ve set up your local environment, and now you want to get that process working in a daily build environment. Maybe you want to automate deployment to a QA or Staging environment. Maybe you’re trying to do continuous deployment to Production. In all these scenarios, you’ll come across a few hiccups when first setting up the new environment. Below I’ll provide some troubleshooting tips for these common issues…