Goals and principles are different for every organization, but they make it easier to make hard decisions, prioritize one developer\u2019s project over another\u2019s, and stop doing things that just aren\u2019t working. You may already have goals and values in place; if not, it\u2019s never too late to get started, because it never ends. <\/p>\n
In this post, I\u2019ll share how and why we implemented one of our most recent changes: moving to Mono-repo<\/em> and One Infra<\/em>, including why we unified our development and infrastructure and what\u2019s next. <\/p>\n To learn more about how our team works, check out Lukas Spie\u00df’ How We Do Code Review<\/a> and Benny Scholtysik’s How We Build SDKs Developers Love<\/a>. <\/p>\n App Center uses a micro-services architecture to give us the flexibility to break things down into small units that perform a single business function and can be developed and deployed independently. When we started, we chose to use multiple repositories.<\/p>\n When we were shipping a first version of the product, this made sense for two reasons: <\/p>\n We have several teams spread across multiple time zones, and, with the above approach, it was challenging to share and standardize code across the multiple repositories. A team member working on one service couldn\u2019t easily clone a repository and know how to get started. Since developers didn\u2019t always have a full understanding of the \u201cbig picture\u201d across App Center, our code reviews weren\u2019t as effective as they could be, and shared code didn\u2019t feel \u201cshared, so we were doubling effort in some scenarios. <\/p>\n Multiple repositories across multiple teams meant each team created their own infrastructure. We\u2019d started with a common direction, using DC\/OS and multiple data sources like SQL Server, Casandra, Table, and Blob storage. But, as teams pushed the product forward, how we set up infrastructure drifted in multiple directions. We were duplicating how we managed and accessed our infrastructure, and each team had to do secret management and rotation. <\/p>\n As we compared this to our \u201cno silos\u201d value, it went against building one team with knowledge across the product. We decided to move to Mono-repo and trunk based development<\/a> and use a common infrastructure for our build and deployment pipeline. Value and goal check: this eliminates silos, helps us work better as one<\/strong> team, and frees us to constantly deliver customer value. <\/p>\n To move our code from multiple repositories in different source providers into one, each team migrated their development or master branch (including its history) into a new Visual Studio Team Services project repo: <\/p>\n We used kebob format (tools-swagger-codegen) for our folders, making descriptions as robust as possible (within a reasonable length) and removing team-specific names for code. For example, we called our user service Vanaheim<\/em> which was confusing to new team members and teams working on other services. When we moved to Mono-repo, Vanaheim<\/em> became accounts-management-service<\/em> a clear, descriptive, and easily understandable identifier. <\/p>\n After a few weeks, we\u2019d fully transitioned, but it\u2019s a constant work in progress; we want it to be a never-ending, iterative process. As we continue development over time, we\u2019ll continuously make our code better, simplifying processes and working together to build better product. <\/p>\n Shifting to Mono-repo gave us an opportunity to rework and consolidate our infrastructure too. Each team used Docker to deploy code into different orchestrators, read secrets their own way, and had their own approach to logging and telemetry. In addition to consolidating repositories, we\u2019d unify and share code in way that didn\u2019t require cloning and duplication. <\/p>\n We use Visual Studio Team Services to consolidate builds, packages, and deployments. Promoting a single artifact reduces our total number of build definitions to one per service or component we create. To get our build definitions working inside of our new Mono-repo, we followed the below steps: <\/p>\n <\/p>\n <\/p>\n We use three environments: integration, staging and production, and two Visual Studio Team Services control our releases. Our integration definition automatically deploys changes merged into\u202fmaster\u202fto the corresponding integration environment. <\/p>\n The majority of our existing integration definition didn\u2019t require any alterations, other than adding a new step to create the git tags. The production definition deploys the integration artifacts to staging and creates an automatic pending approval for a production deployment. After qualifying our staging environment is ready, we generate an approval for production. In the future, as we grow and add more features, we\u2019ll fully automate this, too, allowing releases to go straight to production. <\/p>\n Given our growth mindset approach to development, we\u2019re continuing to iterate and refine our processes. Our next step is to consolidate subscriptions and services, including moving our Docker deployments to Azure Service Fabric as our orchestrator to consolidate our logging and telemetry infrastructure, as well as standardizing how we access and rotate secrets. <\/p>\n This automation and consolidation brings us back to our core values and goal, since every simplified process means each team member spends more time delivering value to developers and less time managing infrastructure. <\/p>\n The move to Mono-repo and a common infrastructure is ongoing, but we\u2019re already seeing some positive results. Team members are more productive, code is less complex, and there\u2019s more knowledge sharing across teams. Teams don\u2019t just work and own one feature area, they work on the most important set of features across the product, so we have all hands on deck for high-priority items. <\/p>\n We\u2019re committed to delivering customer value and making App Center the best CI\/CD experience for all developers, so you can ship better apps faster and focus on delivering value to your users. <\/p>\n Log in<\/a> to see what we\u2019ve been up to, or create your free account<\/a> to get started. <\/p>\nWhy Mono-repo?<\/h2>\n
\n
Going from Multi to Mono(-repo)<\/h2>\n
\n
Creating One Infra<\/h2>\n
\n
<\/li>\n
<\/li>\n
What\u2019s Next<\/h2>\n
Final Thoughts<\/h2>\n