Lets say you’re sequence looks like this: Instead of copying the build configuration and changing some of it’s parameters, you can create a template with a set of configurable parameters. We have a group of users that are the only ones that are allowed editing and running the builds for production evironments the same goes for the staging environment.Īs you add new projects, you will soon notice that the build configurations you create become repetitive. So, why didn’t we group environments per project? That’s because we use those environment groups to handle permissions for project configurations and running builds. Only then do we add the “project” for the required environment. NET, iOS and so on), and inside the platform group we create additional “environment” groups (Development, Staging, Production). So first we create the grouping by platform (PHP. TeamCity allows the creation of hierarchical project trees that allow you to group projects by platform, environment, name, etcetera. So, it’s best to separate projects that are on PHP from. Project Structure and PermissionsĪt Devbridge, we offer different platform and technologies for our projects, such as PHP. In TC you can easily add permission for users and groups per project, which is useful when we have users that need specific permissions for running some of our deployment and build tasks. The outside users are our clients, contributing developers from other companies and other third-parties that might need access to specific projects. Next, we added some additional groups and possibilities to differentiate between our own "internal users" and "outside users". TC synchronized all the required accounts and even groups. Luckily, TC supports LDAP integration, so TC server access was easy for us. We needed a way for all of our developers to have access to our TC server by using their Active Directory credentials. We use the Active Directory domain controller to manage our employee accounts, the groups they belong to and permissions they have. I will introduce some of our favorite TeamCity (TC) features and how we use them in our everyday work. It comes with a bundle of useful features out of the box. Having a background of Jenkins, CruiseControl and GO CD usage, we decided to stick with the JetBrains TeamCity server, that in my opinion is one of the best CI servers. We know that writing clean and modular code allows for a better reusability we want our CI tasks to be reusable in other projects as well. The problem is that the requirements for those tasks change and configuring our automations to match those requirements becomes a harder task than just running a script or tool with specific parameters once or twice. But still, sometimes we have to rely on manual deployments, builds, migrations and other repetitive development tasks. “Automations” - a term we the developers are quite familiar with.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |