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 12 Current »

Migration
  • Are we renaming the Namespaces?
    If we do, now is the time. Our suggestion will be to just do it and also clean up the current namespaces. These changes need to be documented.
  • 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?
    Our suggestion would be to focus on .NET core, so copy the code from the .NET core branches from DD4T and leave those repo's alone. We'll update the readme files to point to the new repo's for SDL.
  • 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:


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?
    We need to make things clearer. Developers expect the same setup.
  • These repo's have to be created on the SDL GitHub:
    • .NET
      • DD4T.Core → DXA.Foundation
      • DD4T.Models → DXA.Models
      • DD4T.MVC → DXA.MVC
      • 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