visual-studio-2010 - obj - gitignore visual studio

Práctica recomendada con.gitignore para cadenas de conexión dentro de App.config o Web.config

Question

He intentado varios enfoques con *.gitignore para administrar cadenas de conexión cuando se trabaja en un equipo más grande.

Desde el repositorio oficial de archivos .gitignore en gitignore , descargué VisualStudio.gitignore y lo usé como punto de partida para todos los proyectos.

Se puede hacer el mismo proceso visitando http://gitignore.io/ , escribiendo VisualStudio y luego descargando el archivo.

El enfoque que utilizo actualmente es aprovechando la propiedad SectionInformation.ConfigSource

<connectionStrings configSource="myConnectionStrings.config" />

y luego agregar myConnectionStrings.config a .gitignore , lo cual es bueno porque no agrega todo el *.config .

También puede usar el mismo myConnectionStrings.config dentro de otro proyecto (su capa MyProject.Data )

<configuration>
  <connectionStrings configSource="myConnectionStrings.config"/>
</configuration>

Solo recuerda configurar Copiar siempre !

También he intentado usar los filters como se describe en Git: ignorar una modificación específica de un archivo de configuración , pero me parece que es una exageración.

Me pregunto si hay algún otro enfoque que se considere una mejor práctica.

Answer 1

No puedo hablar por tu configuración, pero así es como he abordado este problema.

En primer lugar, todos los integrantes de mi equipo utilizan bases de datos locales con la seguridad integrada establecida como verdadera. Esto significa que cuando revisamos los archivos del control de código fuente, es bueno utilizar una configuración local. Así que mi archivo de configuración web se ve así

<add name="appConnString"
   connectionString="Data Source=(local);Initial Catalog=MyDatabaseName;Integrated Security=True;"
   providerName="System.Data.SqlClient" />

Con respecto a la implementación en diferentes entornos, la primera opción que tiene es usar transformaciones. Si no sabes lo que es, lee aquí

Ya que utilizamos Octopus Deploy como nuestra herramienta de implementación, nuestro archivo de transformación tiene la cadena de conexión para "web.release.config" como esta

<add name="appConnString"
   connectionString="{{appConnString}}"
   xdt:Transform="Update" 
   xdt:Locator="Match(name)" />

Cuando Octopus ejecuta su curso, toma el archivo web.config y sobrescribe las secciones relevantes utilizando el archivo de lanzamiento. Luego, dependiendo de a qué entorno / máquina / rama estoy implementando, reemplaza {{appConnString}} con la configuración que se ha configurado para esa implementación.

Estoy seguro de que Visual Studio tiene prácticamente el mismo proceso.

Si no te gusta el proceso de Transformaciones. También puede utilizar un archivo parameters.xml. msdepoy usa este archivo para reemplazar los valores en su web.config en la compilación. Puedes leer más sobre esto here .

Otra consideración es si está hospedando con Azure, puede configurar ciertos reemplazos de configuración en sus diferentes ranuras de implementación hasta el final de la producción.

Estas son solo algunas de las técnicas que he usado y visto que se usan de manera muy efectiva. Algunos tardan un poco en acostumbrarse y también mucha frustración en la configuración, pero tener un sistema de implementación adecuado pagará a largo plazo.

Answer 2

Quizás un poco presuntuosamente, sostengo que no hay necesidad de una política para agregar globos de shell a un archivo. Nunca he oído hablar de "connectionStrings" antes de leer esta pregunta, pero de lo que pude reunir, tienen URI / credenciales para varios backends.

¿Con qué frecuencia cambia un backend? Mejor aún, ¿con qué frecuencia cambia la ruta del archivo de configuración? Probablemente no tan a menudo como para justificar una política . Lo único que necesita es una convención para nombrar los archivos de configuración que contienen estas cadenas de conexión para identificarlos fácilmente con herramientas de automatización.

Así que use sus herramientas o escriba un script y agregue foobarService.config de <connectionStrings configSource="foobarService.config" /> al archivo .gitignore para todos sus backends.

1. Encuentra los archivos.

$ find -name cs.xml

./more/configs/here/cs.xml
./cs.xml
./some/sub/folder/cs.xml

2. obtener nombres de archivos de configuración

$ find -name cs.xml | xargs grep -ho ''[^"]/+/.config''

getImagesService.config
users.config
ldap.config
foobar2k.config
ratpoison.config
moo.config
foo.config
trololol.config
moreconfigz.config
myConnectionStrings.config
data.config
base.config
filebackend.config
offsitewhatever.config

3. ignorarlos

$ find -name cs.xml | xargs grep -ho ''[^"]/+/.config'' >> .gitignore

4. actualiza tu CV

• Marzo de 2014 - diseñador líder de una política de conexión.

Estoy sorprendido de que alguien pregunte sobre consejos para administrar un archivo .gitignore. Esto podría indicar que no veo el cuadro grande. ¿Podrías actualizar tu pregunta con alguna información de fondo? Tengo curiosidad acerca de por qué esta es una pregunta significativa, ya que me cuesta entender que hay una necesidad de establecer las mejores prácticas para agregar una cadena a un archivo.