Sitecore: Deployment, Automated Testing & Build... On Steroids

Clear set of practices which allow you to move your Sitecore builds to the next level.

Transcript

1. Deployment, Automated Testing & Build... On steroids! Alex de Groot @alexdegroot TTMToday.com #devops #agile #lean #basketball #gadgets #innovation #collaboration
2. Universal solutions for quick Builds with Sitecore* Alex de Groot @alexdegroot TTMToday.com * Not universal or a ready-to-use
3. Why do we write software? To create business impact
4. Why do we write software? To create sustainable business impact
5. Why do we write software using Sitecore? To create sustainable marketing impact!
6. How does the high-level marketing process look? Products / Services introduction or change Marketing Strategy Development & Execution Software Development Market Introduction of Product / Service or change
7. So how can we make sustainable marketing impact? Structurally reducing the time it takes to publish to the any channel Old fashioned metrics: Time to Market Cost of Delay
8. Let’s zoom in on the process Products / Services introduction or change Marketing Strategy Development Software Development Market Introduction of Product / Service or change
9. Building for the online channel Marketing Strategy Alignment Marketing Channel Selection Software Team Effort Software Deployment
10. What is really being done? Interpretation of strategy & channel Software Team Effort / Development Build / CI Deployment
11. Where to optimize? LEAN explains us: • To optimize for every single item, not for batches (such as sprint) • To focus on quick feedback • Automate repeatable tasks • To look for places where little human work is not happening or value is added
12. Sweet spot for initial optimizations Interpretation of strategy & channel Software Team Effort / Development Build / CI Deployment
13. Practice #1: Separate Build from Deployment • Simplifies automation (reduces complexity) • Build is for giving feedback about your stuff • Deployment is… complicated stuff • Build should happen repeatedly on a clean computer(1) • Once both are quick (<1 minute), consider combining
14. Practice #2: Manage your dependencies • Dependencies are main source for slow builds • Source Repo is for Source, removing all heavy, big dependencies • Use popular package management tools: NuGet, Bower, CocoaPods, etc • And let is do the caching, not your CI tool • Demand your vendor to deliver packages in the right format!
15. Practice #3: Optimize for throwing code away • Don’t start an intimate relation with your if-statements • Rewriting same functionality usually quicker than editing (and more fun) • Keep your projects(VS, Eclipse, etc) small, tidy and to the point • Use a distributed SCM (Git, Mercurial, BitKeeper) • Use 1 repository per component / project • And yes, now architecture becomes subordinate of the project goal… • Script your boilerplate work, such as project and build creation • For Reusability or ‘generic components’ use the chosen dependency framework
16. Practice #4: Optimize for feedback • Simplify your build steps to 1 action per step so feedback is distinct • Use Gated CI if your build tooling supports this • Consider what sort of feedback you want: • Immediate: Code Analyzers (IDE, Runtime) • Instant: Compile & Unit Test (Check-in Build) • Trend-like / Daily: Static Analysis, Breaking changes
17. Demo Time How could that work for you?
18. Used and useful tools • TFS Online: http://www.visualstudio.com • Generate-aspnet: https://github.com/OmniSharp/generator-aspnet • Git for Windows: https://git-scm.com/download/win • Sitecore NuGet server: https://github.com/adamconn/sitecore-nuget-server
19. Practice #5: (Unit) Test only what makes sense • Every test eats crucial time and CPU cycles • Consider heavily what to test
20. Practice #6: Change your integration approach • Only build source code once • Create packages for integrating components into the large solution • Separate (integration) test components from the real components • Consider Canary Build principles for picking up new releases • Popular package frameworks allow annotations such as 'prerelease'
21. Practice #7: Consider your render engine • The Sitecore render engine is heavy and puts on all sorts of dependencies • Federated Experience Manager does support 80% of the Marketing features • Item Web API for Content (who uses inline editing anyway ;-)) • Generally the industry moves to Browser based & JavaScript • One-page websites • SDL & Adobe dropped their Render Engine support • Remember Google Analytics & Google Webmaster tools? All JavaScript… • Enough alternatives which can run on cheap hosting (NancyFx, ASPNETv5)
22. So how will the development flow look? Development of business feature Create Pull Request Build is kicked off Merge Check Green lights? Merge to Master & Close Pull Request Build of Master triggered Push to NuGet Artifact Server with prerelease flag Deployment Pipeline Triggered
23. Pattern #8: Consider usage of Containers • Containers such as Docker are a very good way to isolate your application • Quick setup for integration runs (clean MongoDB boots in seconds) • Reduces hardware needs heavily • Note: Sitecore support will come available over time with Docker containers on Windows Core 2016. You just won't find IIS support there.
24. Pattern #9: Select real deployment tooling • CI tools often misused as CD tools • Focus of Octopus, GoCD is on release & scaling • Ability to define manual steps, which you can automate later • PowerShell and Bash scale better than your custom C# console app
25. Pattern #10: Make no assumption • Your deployment target might not have anything installed • How clean the server is, there might be unexpected left-overs • Don't assume anything: • Always check if ALL prerequisites are available • Always clean folders, files, log queues, etc, before you start any I/O operation
26. Pattern #11: Don't over complicate your deployment • Complete DTAP doesn't serve a purpose when you integrate and deploy multiple times per day • If all is automated, user acceptance should happen in the same flow
27. Thank You! Alex de Groot @alexdegroot TTMToday.com #devops #agile #lean #basketball #gadgets #innovation #collaboration