0

I am currently working at a company that has a small(2) development team for our ASP.NET WebForms project. This was something we picked up from a previous team. The current team is made up of recent university graduates with little to no experience in source control. We have all read the gitflow page and understand it, we just don't understand how the process should flow once a release is ready and in the master branch.

The previous team, however, did not supply source, so we have been left to rewrite it from the ground up. We introduced source control to the company, and have slowly been trying to clean up our development process. We still don't have any clear development patterns or standards in place due to our employer, but that is a discussion for another time.

To clarify, we are comfortable with source control, but we have no idea how to deploy in a clean, easy to handle way. There is not a single developer in this team that has more than 2 years development in a company.

We work in feature branches and use release branches to push, well, releases, but our deployment pipeline is non existent. We currently pull our master branch directly on to our production server.

Our employer likes to make hotfixes(not the GitFlow kind) at will, without telling the developers. We hit a situation today where the we needed to put live a hotfix, but the employer had made some changes in the way of that, so we had to spend an hour working around those. If we want to apply a hotfix on the production server, we need to checkout our develop branch first, which also means disrupting our clients more than we would like.

The question I have is this, how should we be handling our source control? Should we really be pulling the master branch directly on to our production server?

We are all inexperienced in source control, never using it to supply a product before. I am currently the lead developer, and I am trying to get some order in place before we bring on more developers. Any and all advice is welcome.

|improve this question
  • 3
    I would start by getting buy-in from your employer. Anything you put in will fail if you have people short-circuiting your development process. – Robert Harvey Aug 14 '17 at 16:05
  • I've been told it will stick if I come to him with something. – Mykrosoft Aug 14 '17 at 16:47
  • Note that .NET assemblies can be easily decompiled, so you can have source if you really want/need it. – Robert Harvey Aug 14 '17 at 16:54
  • 2
    The only problem I can see here is the live editing on a production server, made even worse by the lack of communication. Live editing in prod is a costly disaster waiting to happen, and insufficient communication is probably already slowing your development down (and time is money). But fundamentally, those are people problems not tech problems. No version control system or branching strategy can fix that. Also, Git is a source code management system and not really intended for deployment. But that's really not the main issue at hand. – amon Aug 14 '17 at 18:07
0

I am in a very similar situation with a slightly larger team. One major difference is that each member has unique skill sets and experience when it comes to development. The hardest problem that I have experienced is getting not only the company to respect the new development flow, but to get each of the members to stick to the processes agreed upon. Keep in mind, even if the employer does not view this as important, try your best to follow the flow that gets established. You are in a perfect position to setup a flow before your team becomes large and unruly.

The other issue that I ran into recently is that there is a big difference between a web forms application and a web forms website.

https://msdn.microsoft.com/en-us/library/dd547590(v=vs.110).aspx

When it comes to source control, each can be handled very differently. With a web application, the source code should be put in git and compiled to run. With a web site, everything in the directory is automatically compiled and is already in a state that can be used for both development and production. This makes it too easy to just make changes in production and interrupt the flow.

As far as releases and development flow go, we use a multi-step approach that involves the blue / green method.

  1. Development Environment - Dedicated machine for development / Local Copies
  2. Test Environment - Dedicated Server/Site
  3. Production Environment (Blue) - Dedicated Server/Site
  4. Production Environment (Green) - Dedicated Server/Site

Normal development or branch development is done on the Dev Environment. The Dev environment can be run on a local developer machine or there can be a system that is dedicated to running it. Once happy with the code changes, we push the branch to the Test Environment. This is where we run usability and feature testing. This environment is attached to dummy database with fake data. Once we are satisfied with the testing, we merge the changes into the master and push the release to Blue. We then do a few more little test just to make sure the live data is showing the correct results. Once we have team lead approval, we flip the Blue to Green.

This means that the site directory for the Production Environment blue become the live instance, while the green version remains available but offline. This is great to have if something fails that was uncaught during testing and a rollback is needed.

This can all be done in virtuals and even on the same IIS server if needed. It might sound a little intimidating at first, but it does provide a great deal of redundancy and protection when developing an ASP.net Webforms website.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.