Developer Group - Sitecore Application Lifecycle Management

Editor's Notes

• #2: We are all lazy gits! But this is not a bad thing… Some of my most brilliant work has been done simply to avoid me having to repeat boring things again and again. I think this is why we inherently all love the fact that DevOps My name is…
• #3: The market changes and so will the requirements Marketeers will always want something else or more All marketing divisions will mature and need more tools and possibilities We are not in the business of making turnkey solution and we are not in the business of setting up standard systems. Everything we do is about customization and change. The market is changing, and the customers expectations on what service you can deliver and the time to market is changing. Meanwhile the enterprises are turning their marketing investments to larger platforms Just because the platform is best-of-breed, the solution might not be
• #4: We are not in the business of making turnkey solution and we are not in the business of setting up standard systems. Everything we do is about customization and change. The market is changing, and the customers expectations on what service you can deliver and the time to market is changing. Meanwhile the enterprises are turning their marketing investments to larger platforms Just because the platform is best-of-breed, the solution might not be
• #5: For many years IT projects has been treated like construction projects. Start, Build, Deliver – nothing more. Even agile methodology in SI’s and Agencies have typically been treated as a number of sprints ending with a release The “Build and Release” culture is deeply rooted in the development community “The only thing constant in life is change” We know that the market is changing all the time We know that the world of marketing and the tools and competencies are evolving Why are we as developers often building like there is no tomorrow? Why are many Sitecore implementation projects still acting like the up front requirements is eternal? We need to make it possible for the platforms we build to change and evolve We need to move from a project and delivery based approach to an agile and process based approach We need to focus on the entire application lifecycle, and not just the build and delivery
• #6: Typical lifecycle Whether waterfall or agile methodology
• #7: 1. We all know that developing a single Sitecore solution on our own machine is typically very simple and easy. If only all processes in software development was as easy as that, right? 2. Once you start scaling to multiple developers, that requires conventions, tools and meticulous processes 3. Likewise, deploying to a single server can be a simple manual process, and there are tools in Sitecore and out there to help you 4. But once you get multiple environments and scaled setups, things like configuration management and recovery processes needs to described and planned 5. Continuous integration, unit testing and DevOps is on everybody's lips these days. In many of these processes and tasks, Sitecore will not particularly lend a hand, and you have to define the conventions and processes to make it work for you. 6. And once you bring in versioning and perhaps have dependencies to external parties integrating with your solution, things like branching and release management becomes important. 7. And if major releases are being developed and tested while you need to do patching and hotfixes on specific environments, we need to be able to recreate every version, including the associated versions of Sitecore, modules, content databases and so on. Which in other words requires dependency manager processes and conventions. 8. Finally, all this naturally needs to be covered in the agile process that you are all running with 2 week sprints. We cannot afford to waste time setting up test or development environments or got through painful minor upgrades. So we need all these processes to be fully automated and completely trustworthy.
• #8: Optimized Processes: Focus on What Is Important. Choosing the Right Tool for the Job. Support Distributed and Simultaneous Teams. Improved Quality Decrease Chances of Manual Errors. Make It Possible to Automate and Improve Testing. Tracability: Reproduce and Recreate. Greater Flexibility Faster Time to Market Predictability in the changes. Faster upgrades, additions, substitutions and alterations.
• #10: We all love our power tools. Continuous Delivery, Continuous Integration and DevOps are the new shiny toys we all want to work with. We want to install those great pieces of software and watch them run. We all want unit testing because the cool guys says it what you should do. Remember to always keep the eyes on the WHY and not the HOW. Make sure that the tools are built around the processes. If you do not implement the processes and conventions successfully, the tools will be useless. And the key here is understanding: If the people you work with do not understand your processes or conventions or why they are needed, they are not the stupid ones! You have failed to explain it in the right manner. (Maybe example of timesheets)
• #18: Function before Type
• #49: Lets look at an example of a typical deployment of Sitecore and investigate what is involved
• #52: In order to consistently
• #53: In order to consistently
• #59: Many processes in ALM Conventions which works across are key
• #61: The work on culture and conventions never stops Don’t be overly ambitious and connects with the last point: Don’t do it because you think the tool or process is cool, do it because you have carefully considered why you want to do it. Thereby the business will buy in!