Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Migration
  • Are we renaming the Namespaces?
  • We are removing all the current obsolete data.
  • We focus on .NET Core for future proofing.
  • Are we moving the repo's or just copy over the code?
  • There needs to be a core team, who have access to the tools and repo's (SDL and Community). This team is responsible for accepting and denying pull requests. The team should consist of people actively involved from both sides. These are currently:
    • Quirijn Slings (.NET)
    • Siawash Shibani (.NET)
    • Thijs Borst (.NET)
    • Raimond Kemphees (Java)
    • Rogier Oudshoorn (Java)
    • Bart Koopman
    • Rick Pannekoek


Git repo's
  • These need to be moved to the SDL git account.
  • We need a core team with access to the repo's.
  • We need access to setup CI.
  • We need to rename them from DD4T to DXA
  • One repo per module
  • Split java up in pieces as we did with .NET?
  • These repo's have to be created on the SDL GitHub:
    • .NET
      • DD4T.Core → DXA.Foundation
      • DD4T.Models → DXA.Models
      • DD4T.Provider.SDLWeb8 → DXA.Providers.SDLWeb8
      • DD4T.Provider.SDLTridion2013SP1 → DXA.Providers.SDLTridion2013
      • DD4T.TridionTemplate → DXA.TBB
      • DD4T.DI.Unity → DXA.DI.Unity
      • DD4T.DI.Ninject → DXA.DI.Ninject
      • DD4T.DI.Autofac →  DXA.DI.Autofac
      • DD4T.Logging.Log4net → DXA.Logging.Log4net
      • DD4T.Logging.NLog → DXA.Logging.NLog
      • DD4T.Caching.ApacheMQ → DXA.Caching.ApacheMQ
      • dd4t-cachechannel → DXA.Extensions.JMSCachingChannel
    • Java
      • ?



Tools
  • Public CI service
  • Public SonarQube.
  • Docker swarm? Docker Datacenter? Docker Cloud? AWS?
  • CME and CD environment we can test on (All supported versions?)
  • Repository which hosts Maven, NuGet, NPM and Docker Images. We deploy there and to the Central Repo's.
  • Deploy Tool?


Testing
  • Unit tests with code coverage (SonarQube)
  • Automated tests
  • Generate a Docker Container to test new features and pull requests and run the automated tests against.


Development
  • Move to fork / pull requests, not everybody is in the core team, the core team can test and accept pull requests. The core team uses the same process.
  • Develop is the main branch. This is where we fork from.
  • Master is the release branch
  • We tag releases
  • We don't run code analysis on the pull requests, this because we need a version number for it and bs pull requests will interfere with the quality of the reports.
  • No labels